[Qemu-devel] "make run-tcg-tests-s390x-linux-user" not working for me

[David Hildenbrand]

Hi,

for now I was able to run TCG tests using "make
run-tcg-tests-s390x-linux-user". Lately, trying to run the tests always
results in

t460s: ~/git/qemu vx $ LANG=C make run-tcg-tests-s390x-linux-user
make[1]: Entering directory '/home/dhildenb/git/qemu/slirp'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/dhildenb/git/qemu/slirp'
CHK version_gen.h
  BUILD   TCG tests for s390x-linux-user
  BUILD   s390x guest-tests SKIPPED
  RUN TCG tests for s390x-linux-user
  RUN tests for s390x SKIPPED

t460s: ~/git/qemu vx $ LANG=C make check-tcg
make[1]: Entering directory '/home/dhildenb/git/qemu/slirp'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/dhildenb/git/qemu/slirp'
CHK version_gen.h
  BUILD   TCG tests for s390x-softmmu
  BUILD   s390x guest-tests SKIPPED
  RUN TCG tests for s390x-softmmu
  RUN tests for s390x SKIPPED
  BUILD   TCG tests for s390x-linux-user
  BUILD   s390x guest-tests SKIPPED
  RUN TCG tests for s390x-linux-user
  RUN tests for s390x SKIPPED

I am using "./configure --target-list=s390x-softmmu,s390x-linux-user
--enable-sdl --enable-spice --enable-kvm"

What am I missing? Why is the build skipped?

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v3] migratioin/ram: leave RAMBlock->bmap blank on allocating

[Peter Xu]

On Tue, Jun 04, 2019 at 02:17:27PM +0800, Wei Yang wrote:
> During migration, we would sync bitmap from ram_list.dirty_memory to
> RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap().
> 
> Since we set RAMBlock.bmap and ram_list.dirty_memory both to all 1, this
> means at the first round this sync is meaningless and is a duplicated
> work.
> 
> Leaving RAMBlock->bmap blank on allocating would have a side effect on
> migration_dirty_pages, since it is calculated from the result of
> cpu_physical_memory_sync_dirty_bitmap(). To keep it right, we need to
> set migration_dirty_pages to 0 in ram_state_init().
> 
> Signed-off-by: Wei Yang 
> Reviewed-by: Dr. David Alan Gilbert 

Thanks for updating the comments.

Acked-by: Peter Xu 

-- 
Peter Xu

Re: [Qemu-devel] [Qemu-ppc] [PATCH v9 6/6] migration: Include migration support for machine check handling

[Aravinda Prasad]

On Monday 03 June 2019 09:10 PM, Greg Kurz wrote:
> On Wed, 29 May 2019 11:10:57 +0530
> Aravinda Prasad  wrote:
> 
>> This patch includes migration support for machine check
>> handling. Especially this patch blocks VM migration
>> requests until the machine check error handling is
>> complete as (i) these errors are specific to the source
>> hardware and is irrelevant on the target hardware,
>> (ii) these errors cause data corruption and should
>> be handled before migration.
>>
>> Signed-off-by: Aravinda Prasad 
>> ---
> 
> LGTM, just one issue: machine reset should del and free the blocker as well,
> otherwise QEMU would crash if spapr_mce_req_event() is called again.

Sure.


> 
>>  hw/ppc/spapr.c |   20 
>>  hw/ppc/spapr_events.c  |   17 +
>>  hw/ppc/spapr_rtas.c|4 
>>  include/hw/ppc/spapr.h |2 ++
>>  4 files changed, 43 insertions(+)
>>
>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>> index e8a77636..31c4850 100644
>> --- a/hw/ppc/spapr.c
>> +++ b/hw/ppc/spapr.c
>> @@ -2104,6 +2104,25 @@ static const VMStateDescription vmstate_spapr_dtb = {
>>  },
>>  };
>>  
>> +static bool spapr_fwnmi_needed(void *opaque)
>> +{
>> +SpaprMachineState *spapr = (SpaprMachineState *)opaque;
>> +
>> +return (spapr->guest_machine_check_addr == -1) ? 0 : 1;
>> +}
>> +
>> +static const VMStateDescription vmstate_spapr_machine_check = {
>> +.name = "spapr_machine_check",
>> +.version_id = 1,
>> +.minimum_version_id = 1,
>> +.needed = spapr_fwnmi_needed,
>> +.fields = (VMStateField[]) {
>> +VMSTATE_UINT64(guest_machine_check_addr, SpaprMachineState),
>> +VMSTATE_INT32(mc_status, SpaprMachineState),
>> +VMSTATE_END_OF_LIST()
>> +},
>> +};
>> +
>>  static const VMStateDescription vmstate_spapr = {
>>  .name = "spapr",
>>  .version_id = 3,
>> @@ -2137,6 +2156,7 @@ static const VMStateDescription vmstate_spapr = {
>>  &vmstate_spapr_dtb,
>>  &vmstate_spapr_cap_large_decr,
>>  &vmstate_spapr_cap_ccf_assist,
>> +&vmstate_spapr_machine_check,
>>  NULL
>>  }
>>  };
>> diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
>> index 573c0b7..35e21e4 100644
>> --- a/hw/ppc/spapr_events.c
>> +++ b/hw/ppc/spapr_events.c
>> @@ -41,6 +41,7 @@
>>  #include "qemu/bcd.h"
>>  #include "hw/ppc/spapr_ovec.h"
>>  #include 
>> +#include "migration/blocker.h"
>>  
>>  #define RTAS_LOG_VERSION_MASK   0xff00
>>  #define   RTAS_LOG_VERSION_60x0600
>> @@ -855,6 +856,22 @@ static void spapr_mce_dispatch_elog(PowerPCCPU *cpu, 
>> bool recovered)
>>  void spapr_mce_req_event(PowerPCCPU *cpu, bool recovered)
>>  {
>>  SpaprMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
>> +int ret;
>> +Error *local_err = NULL;
>> +
>> +error_setg(&spapr->fwnmi_migration_blocker,
>> +"Live migration not supported during machine check handling");
>> +ret = migrate_add_blocker(spapr->fwnmi_migration_blocker, &local_err);
>> +if (ret < 0) {
>> +/*
>> + * We don't want to abort and let the migration to continue. In a
>> + * rare case, the machine check handler will run on the target
>> + * hardware. Though this is not preferable, it is better than 
>> aborting
>> + * the migration or killing the VM.
>> + */
>> +error_free(spapr->fwnmi_migration_blocker);
>> +warn_report_err(local_err);
>> +}
>>  
>>  while (spapr->mc_status != -1) {
>>  /*
>> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
>> index 91a7ab9..c849223 100644
>> --- a/hw/ppc/spapr_rtas.c
>> +++ b/hw/ppc/spapr_rtas.c
>> @@ -50,6 +50,7 @@
>>  #include "target/ppc/mmu-hash64.h"
>>  #include "target/ppc/mmu-book3s-v3.h"
>>  #include "kvm_ppc.h"
>> +#include "migration/blocker.h"
>>  
>>  static void rtas_display_character(PowerPCCPU *cpu, SpaprMachineState 
>> *spapr,
>> uint32_t token, uint32_t nargs,
>> @@ -404,6 +405,9 @@ static void rtas_ibm_nmi_interlock(PowerPCCPU *cpu,
>>  spapr->mc_status = -1;
>>  qemu_cond_signal(&spapr->mc_delivery_cond);
>>  rtas_st(rets, 0, RTAS_OUT_SUCCESS);
>> +migrate_del_blocker(spapr->fwnmi_migration_blocker);
>> +error_free(spapr->fwnmi_migration_blocker);
>> +spapr->fwnmi_migration_blocker = NULL;
>>  }
>>  }
>>  
>> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
>> index bd75d4b..6c0cfd8 100644
>> --- a/include/hw/ppc/spapr.h
>> +++ b/include/hw/ppc/spapr.h
>> @@ -214,6 +214,8 @@ struct SpaprMachineState {
>>  SpaprCapabilities def, eff, mig;
>>  
>>  unsigned gpu_numa_id;
>> +
>> +Error *fwnmi_migration_blocker;
>>  };
>>  
>>  #define H_SUCCESS 0
>>
>>
> 

-- 
Regards,
Aravinda

[Qemu-devel] [PATCH] linux-user: fix build with 5.2-rc2 kernel headers

[Christian Borntraeger]

Since kernel commit 0768e17073dc527ccd ("net: socket: implement 64-bit
timestamps") the linux kernel headers (those installed on the build
system, not those that are synced to QEMU) will make qemu-user fail to
build:

/root/rpmbuild/BUILD/qemu-4.0.50/linux-user/ioctls.h:222:9: error: 'SIOCGSTAMP' 
undeclared here (not in a function); did you mean 'SIOCSRARP'?
  222 |   IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
  | ^~

Let us fix this by including  "linux/sockios.h" instead of relying on
"sys/socket.h" providing those defines via an include chain.

Cc: Riku Voipio 
Cc: Laurent Vivier 
Cc: Arnd Bergmann 
Reported-by: Gerhard Stenzel 
Signed-off-by: Christian Borntraeger 
---
 linux-user/syscall.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index efa3ec2837..7332be9b06 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.21.0

Re: [Qemu-devel] Deprecation policy and build dependencies

[Philippe Mathieu-Daudé]

On 6/3/19 8:16 PM, Cornelia Huck wrote:
> On Mon, 3 Jun 2019 14:02:16 -0400
> John Snow  wrote:
[...]
>> I would rather not support Python2 a day after the clock expires.
>>
>>> I didn't bother checking Debian, Ubuntu LTS and SLES.
>>>
>>> For hosts other than Linux, we're less ambitious.
>>>   
>>
>> That policy strikes me as weird, because RHEL7 is not going to be, in
>> general, using the latest and greatest QEMU. Usually stable versions of
>> distros stick with the versions of the programs that came out at the time.
> 
> I think the idea was that folks might actually develop on a 'stable'
> distro (in a previous life, I used to complain quite often that
> building QEMU on a stable distro broke... it was one of my main
> development machines, but not controlled by me).
> 
>>
>> What's the benefit of making sure that stable platforms can continue to
>> run the *newest* QEMU? Is this even a reasonable restriction? If you are
>> running RHEL7, how many projects do you expect to be able to git clone
>> and build and have that work with the rest of your legacy/stable
>> dependencies?
>>
>> RHEL7 uses a 1.5.3 based version. I don't think it matters if we update
>> 4.2 to be Python3 only, really.
> 
> It depends on how old the distro is and what update policy it
> uses... if parts of it are regularly updated, it might actually be
> usable. In this case, I think we really need to interpret our policy
> to include EPEL, or it is completely nuts.

Red Hat supports Docker on RHEL 7 and above.

Docker solved all my problems, as long as a host can install Docker, I
can build on old or edge images. I don't install plenty of dependencies
on my testing hosts, but in trashable docker images. For regular testing
I use image snapshots.

You need a sysadmin (or root access) to install the docker daemon however.

[Qemu-devel] [QUESTION] How to reduce network latency to improve netperf TCP_RR drastically?

[Like Xu]

Hi Michael，

At https://www.linux-kvm.org/page/NetworkingTodo, there is an entry for 
network latency saying:


---
reduce networking latency:
 allow handling short packets from softirq or VCPU context
 Plan:
   We are going through the scheduler 3 times
   (could be up to 5 if softirqd is involved)
   Consider RX: host irq -> io thread -> VCPU thread ->
   guest irq -> guest thread.
   This adds a lot of latency.
   We can cut it by some 1.5x if we do a bit of work
   either in the VCPU or softirq context.
 Testing: netperf TCP RR - should be improved drastically
  netperf TCP STREAM guest to host - no regression
 Contact: MST
---

I am trying to make some contributions to improving netperf TCP_RR.
Could you please share more ideas or plans or implemental details to 
make it happen?


Thanks,
Like Xu

Re: [Qemu-devel] [PULL 26/44] spapr/xive: add KVM support

[Alexey Kardashevskiy]

On 29/05/2019 16:49, David Gibson wrote:
> From: Cédric Le Goater 
> 
> This introduces a set of helpers when KVM is in use, which create the
> KVM XIVE device, initialize the interrupt sources at a KVM level and
> connect the interrupt presenters to the vCPU.
> 
> They also handle the initialization of the TIMA and the source ESB
> memory regions of the controller. These have a different type under
> KVM. They are 'ram device' memory mappings, similarly to VFIO, exposed
> to the guest and the associated VMAs on the host are populated
> dynamically with the appropriate pages using a fault handler.
> 
> Signed-off-by: Cédric Le Goater 
> Reviewed-by: David Gibson 
> Message-Id: <20190513084245.25755-3-...@kaod.org>
> Signed-off-by: David Gibson 


This one breaks my setup - it boots up to:


ipr: IBM Power RAID SCSI Device Driver version: 2.6.4 (March 14, 2017)
__vio_register_driver: driver ibmvscsi registering
ibmvscsi 7101: SRP_VERSION: 16.a
ibmvscsi 7101: Maximum ID: 64 Maximum LUN: 32 Maximum Channel: 3
scsi host0: IBM POWER Virtual SCSI Adapter 1.5.9


and hangs. Here is the command line:


/home/aik/pbuild/qemu-aikrhel74alt-ppc64/ppc64-softmmu/qemu-system-ppc64 \
-nodefaults \
-chardev stdio,id=STDIO0,signal=off,mux=on \
-device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
-mon id=MON0,chardev=STDIO0,mode=readline -nographic -vga none \
-enable-kvm \
-device nec-usb-xhci,id=nec-usb-xhci0 -m 16G \
-netdev "user,id=USER0,hostfwd=tcp::2223-:22" \
-device "virtio-net-pci,id=vnet0,mac=C0:41:49:4b:00:00,netdev=USER0" \
img/u1804-64G-cuda10.1-418.67-swiotlb.qcow2 \
-machine pseries,cap-cfpc=broken,cap-htm=off,ic-mode=xive -snapshot \
-smp 1,threads=1 -bios ./slof.bin \
-L /home/aik/t/qemu-ppc64-bios/ \
-trace events=qemu_trace_events -d guest_errors \
-chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.user2223 \
-mon chardev=SOCKET0,mode=control


The host kernel is v5.2-rc2. The next patch - 0c575703e487 "spapr/xive:
add hcall support when under KVM" - fixes this though but the question
is now if xive emulation in qemu still works (how do I verify it?).


Any clues? Thanks,


> ---
>  hw/intc/Makefile.objs   |   1 +
>  hw/intc/spapr_xive.c|  48 +++-
>  hw/intc/spapr_xive_kvm.c| 237 
>  hw/intc/xive.c  |  21 +++-
>  hw/ppc/Kconfig  |   5 +
>  hw/ppc/spapr_irq.c  |   6 +-
>  include/hw/ppc/spapr_xive.h |  10 ++
>  include/hw/ppc/xive.h   |  13 ++
>  target/ppc/kvm.c|   7 ++
>  target/ppc/kvm_ppc.h|   6 +
>  10 files changed, 344 insertions(+), 10 deletions(-)
>  create mode 100644 hw/intc/spapr_xive_kvm.c
> 
> diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
> index df712c3e6c..03019b9a03 100644
> --- a/hw/intc/Makefile.objs
> +++ b/hw/intc/Makefile.objs
> @@ -39,6 +39,7 @@ obj-$(CONFIG_XICS_SPAPR) += xics_spapr.o
>  obj-$(CONFIG_XICS_KVM) += xics_kvm.o
>  obj-$(CONFIG_XIVE) += xive.o
>  obj-$(CONFIG_XIVE_SPAPR) += spapr_xive.o
> +obj-$(CONFIG_XIVE_KVM) += spapr_xive_kvm.o
>  obj-$(CONFIG_POWERNV) += xics_pnv.o pnv_xive.o
>  obj-$(CONFIG_ALLWINNER_A10_PIC) += allwinner-a10-pic.o
>  obj-$(CONFIG_S390_FLIC) += s390_flic.o
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index 62e13ac353..27632683e6 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -174,7 +174,7 @@ void spapr_xive_pic_print_info(SpaprXive *xive, Monitor 
> *mon)
>  }
>  }
>  
> -static void spapr_xive_map_mmio(SpaprXive *xive)
> +void spapr_xive_map_mmio(SpaprXive *xive)
>  {
>  sysbus_mmio_map(SYS_BUS_DEVICE(xive), 0, xive->vc_base);
>  sysbus_mmio_map(SYS_BUS_DEVICE(xive), 1, xive->end_base);
> @@ -251,6 +251,9 @@ static void spapr_xive_instance_init(Object *obj)
>  object_initialize_child(obj, "end_source", &xive->end_source,
>  sizeof(xive->end_source), TYPE_XIVE_END_SOURCE,
>  &error_abort, NULL);
> +
> +/* Not connected to the KVM XIVE device */
> +xive->fd = -1;
>  }
>  
>  static void spapr_xive_realize(DeviceState *dev, Error **errp)
> @@ -259,6 +262,7 @@ static void spapr_xive_realize(DeviceState *dev, Error 
> **errp)
>  XiveSource *xsrc = &xive->source;
>  XiveENDSource *end_xsrc = &xive->end_source;
>  Error *local_err = NULL;
> +MachineState *machine = MACHINE(qdev_get_machine());
>  
>  if (!xive->nr_irqs) {
>  error_setg(errp, "Number of interrupt needs to be greater 0");
> @@ -305,6 +309,32 @@ static void spapr_xive_realize(DeviceState *dev, Error 
> **errp)
>  xive->eat = g_new0(XiveEAS, xive->nr_irqs);
>  xive->endt = g_new0(XiveEND, xive->nr_ends);
>  
> +xive->nodename = g_strdup_printf("interrupt-controller@%" PRIx64,
> +   xive->tm_base + XIVE_TM_USER_PAGE * (1 << 
> TM_SHIFT));
> +
> +qemu_register_reset(spapr_xive_reset, dev);
> +
> +if (kvm_enabled() && machine_kernel_irqchip_allowed(machine)) {
> +

Re: [Qemu-devel] "make run-tcg-tests-s390x-linux-user" not working for me

[David Hildenbrand]

On 04.06.19 09:17, David Hildenbrand wrote:
> Hi,
> 
> for now I was able to run TCG tests using "make
> run-tcg-tests-s390x-linux-user". Lately, trying to run the tests always
> results in
> 
> t460s: ~/git/qemu vx $ LANG=C make run-tcg-tests-s390x-linux-user
> make[1]: Entering directory '/home/dhildenb/git/qemu/slirp'
> make[1]: Nothing to be done for 'all'.
> make[1]: Leaving directory '/home/dhildenb/git/qemu/slirp'
> CHK version_gen.h
>   BUILD   TCG tests for s390x-linux-user
>   BUILD   s390x guest-tests SKIPPED
>   RUN TCG tests for s390x-linux-user
>   RUN tests for s390x SKIPPED
> 
> t460s: ~/git/qemu vx $ LANG=C make check-tcg
> make[1]: Entering directory '/home/dhildenb/git/qemu/slirp'
> make[1]: Nothing to be done for 'all'.
> make[1]: Leaving directory '/home/dhildenb/git/qemu/slirp'
> CHK version_gen.h
>   BUILD   TCG tests for s390x-softmmu
>   BUILD   s390x guest-tests SKIPPED
>   RUN TCG tests for s390x-softmmu
>   RUN tests for s390x SKIPPED
>   BUILD   TCG tests for s390x-linux-user
>   BUILD   s390x guest-tests SKIPPED
>   RUN TCG tests for s390x-linux-user
>   RUN tests for s390x SKIPPED
> 
> I am using "./configure --target-list=s390x-softmmu,s390x-linux-user
> --enable-sdl --enable-spice --enable-kvm"
> 
> What am I missing? Why is the build skipped?
> 

BTW, docker seems to be working fine, just tried with "make
docker-test-build@debian-armhf-cross J=n"

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] "make run-tcg-tests-s390x-linux-user" not working for me

[David Hildenbrand]

On 04.06.19 09:25, David Hildenbrand wrote:
> On 04.06.19 09:17, David Hildenbrand wrote:
>> Hi,
>>
>> for now I was able to run TCG tests using "make
>> run-tcg-tests-s390x-linux-user". Lately, trying to run the tests always
>> results in
>>
>> t460s: ~/git/qemu vx $ LANG=C make run-tcg-tests-s390x-linux-user
>> make[1]: Entering directory '/home/dhildenb/git/qemu/slirp'
>> make[1]: Nothing to be done for 'all'.
>> make[1]: Leaving directory '/home/dhildenb/git/qemu/slirp'
>> CHK version_gen.h
>>   BUILD   TCG tests for s390x-linux-user
>>   BUILD   s390x guest-tests SKIPPED
>>   RUN TCG tests for s390x-linux-user
>>   RUN tests for s390x SKIPPED
>>
>> t460s: ~/git/qemu vx $ LANG=C make check-tcg
>> make[1]: Entering directory '/home/dhildenb/git/qemu/slirp'
>> make[1]: Nothing to be done for 'all'.
>> make[1]: Leaving directory '/home/dhildenb/git/qemu/slirp'
>> CHK version_gen.h
>>   BUILD   TCG tests for s390x-softmmu
>>   BUILD   s390x guest-tests SKIPPED
>>   RUN TCG tests for s390x-softmmu
>>   RUN tests for s390x SKIPPED
>>   BUILD   TCG tests for s390x-linux-user
>>   BUILD   s390x guest-tests SKIPPED
>>   RUN TCG tests for s390x-linux-user
>>   RUN tests for s390x SKIPPED
>>
>> I am using "./configure --target-list=s390x-softmmu,s390x-linux-user
>> --enable-sdl --enable-spice --enable-kvm"
>>
>> What am I missing? Why is the build skipped?
>>
> 
> BTW, docker seems to be working fine, just tried with "make
> docker-test-build@debian-armhf-cross J=n"
> 

Turns out I had to rerun ./configure (it didn't include HAVE_USER_DOCKER
for some reason).

Sorry for the noise :)

-- 

Thanks,

David / dhildenb

[Qemu-devel] [PATCH v2 4/5] virtio: Don't change "started" flag on virtio_vmstate_change()

[elohimes]

From: Xie Yongji 

We will call virtio_set_status() on virtio_vmstate_change().
The "started" flag should not be changed in this case. Otherwise,
we may get an incorrect value when we set "started" flag but
not set DRIVER_OK in source VM.

Signed-off-by: Xie Yongji 
---
 hw/virtio/virtio.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 3dc2f8c223..3960619bd4 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -1162,9 +1162,13 @@ 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 ((vdev->status & VIRTIO_CONFIG_S_DRIVER_OK) !=
+(val & VIRTIO_CONFIG_S_DRIVER_OK)) {
+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) {
-- 
2.17.1

[Qemu-devel] [PATCH v2 0/5] virtio: fix some issues of "started" and "start_on_kick" flag

[elohimes]

From: Xie Yongji 

We introduced two flags "started" and "start_on_kick" to indicate virtio
device's state before. But there still are some problems with them. So
we try to fixup them in this patchset.

The patch 1 fixes a regression bug that old guest is not able to boot with
vhost-user-blk device.

The patch 2 set "start_on_kick" flag for legacy devices.

The patch 3,4 fix some problems with "started" and "start_on_kick" flag.

The patch 5 introduces a "use-started" property to avoid a migration
issue under Greg Kurz's suggestion [1].

[1] https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg06247.html

v2:
- Recalculate "start_on_kick" flag after migration instead of migrating
  it
- Set "start_on_kick" flag for legacy devices
- Avoid setting "started" flag when "use_started" property is true
- Set "use_started" to false by hw_compat_4_0_1 instead of hw_compat_4_0

Xie Yongji (5):
  virtio: Set "start_on_kick" on virtio_set_features()
  virtio: Set "start_on_kick" for legacy devices
  virtio: Make sure we get correct state of device on
handle_aio_output()
  virtio: Don't change "started" flag on virtio_vmstate_change()
  virtio: add "use-started" property

 hw/block/vhost-user-blk.c  |  4 +--
 hw/core/machine.c  |  4 ++-
 hw/virtio/virtio.c | 53 ++
 include/hw/virtio/virtio.h | 23 -
 4 files changed, 58 insertions(+), 26 deletions(-)

-- 
2.17.1

[Qemu-devel] [PATCH v2 2/5] virtio: Set "start_on_kick" for legacy devices

[elohimes]

From: Xie Yongji 

Besides virtio 1.0 transitional devices, we should also
set "start_on_kick" flag for legacy devices (virtio 0.9).

Signed-off-by: Xie Yongji 
---
 hw/virtio/virtio.c | 2 --
 include/hw/virtio/virtio.h | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 6508b2faad..6ec45d8f0a 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2080,7 +2080,6 @@ int virtio_set_features(VirtIODevice *vdev, uint64_t val)
 }
 
 if (!vdev->started &&
-virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1) &&
 !virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
 vdev->start_on_kick = true;
 }
@@ -2236,7 +2235,6 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f, int 
version_id)
 }
 
 if (!vdev->started &&
-virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1) &&
 !virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
 vdev->start_on_kick = true;
 }
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 27c0efc3d0..303242b3c2 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -106,7 +106,7 @@ struct VirtIODevice
 bool vm_running;
 bool broken; /* device in invalid state, needs reset */
 bool started;
-bool start_on_kick; /* virtio 1.0 transitional devices support that */
+bool start_on_kick; /* when virtio 1.0 feature has not been negotiated */
 VMChangeStateEntry *vmstate;
 char *bus_name;
 uint8_t device_endian;
-- 
2.17.1

[Qemu-devel] [PATCH v2 5/5] virtio: add "use-started" property

[elohimes]

From: Xie Yongji 

In order to avoid migration issues, we introduce a "use-started"
property to the base virtio device to indicate whether use
"started" flag or not. This property will be true by default and
set to false when machine type <= 4.0.1.

Signed-off-by: Xie Yongji 
---
 hw/block/vhost-user-blk.c  |  4 ++--
 hw/core/machine.c  |  4 +++-
 hw/virtio/virtio.c | 21 -
 include/hw/virtio/virtio.h | 21 +
 4 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
index 9cb61336a6..85bc4017e7 100644
--- a/hw/block/vhost-user-blk.c
+++ b/hw/block/vhost-user-blk.c
@@ -191,7 +191,7 @@ static void vhost_user_blk_stop(VirtIODevice *vdev)
 static void vhost_user_blk_set_status(VirtIODevice *vdev, uint8_t status)
 {
 VHostUserBlk *s = VHOST_USER_BLK(vdev);
-bool should_start = vdev->started;
+bool should_start = virtio_device_started(vdev, status);
 int ret;
 
 if (!vdev->vm_running) {
@@ -317,7 +317,7 @@ static int vhost_user_blk_connect(DeviceState *dev)
 }
 
 /* restore vhost state */
-if (vdev->started) {
+if (virtio_device_started(vdev, vdev->status)) {
 ret = vhost_user_blk_start(vdev);
 if (ret < 0) {
 error_report("vhost-user-blk: vhost start failed: %s",
diff --git a/hw/core/machine.c b/hw/core/machine.c
index f1a0f45f9c..133c113ebf 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -24,7 +24,9 @@
 #include "hw/pci/pci.h"
 #include "hw/mem/nvdimm.h"
 
-GlobalProperty hw_compat_4_0_1[] = {};
+GlobalProperty hw_compat_4_0_1[] = {
+{ "virtio-device", "use-started", "false" },
+};
 const size_t hw_compat_4_0_1_len = G_N_ELEMENTS(hw_compat_4_0_1);
 
 GlobalProperty hw_compat_4_0[] = {};
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 3960619bd4..9af2e339af 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -1165,10 +1165,7 @@ int virtio_set_status(VirtIODevice *vdev, uint8_t val)
 
 if ((vdev->status & VIRTIO_CONFIG_S_DRIVER_OK) !=
 (val & VIRTIO_CONFIG_S_DRIVER_OK)) {
-vdev->started = val & VIRTIO_CONFIG_S_DRIVER_OK;
-if (unlikely(vdev->start_on_kick && vdev->started)) {
-vdev->start_on_kick = false;
-}
+virtio_set_started(vdev, val & VIRTIO_CONFIG_S_DRIVER_OK);
 }
 
 if (k->set_status) {
@@ -1539,8 +1536,7 @@ static bool virtio_queue_notify_aio_vq(VirtQueue *vq)
 ret = vq->handle_aio_output(vdev, vq);
 
 if (unlikely(vdev->start_on_kick)) {
-vdev->started = true;
-vdev->start_on_kick = false;
+virtio_set_started(vdev, true);
 }
 }
 
@@ -1560,8 +1556,7 @@ static void virtio_queue_notify_vq(VirtQueue *vq)
 vq->handle_output(vdev, vq);
 
 if (unlikely(vdev->start_on_kick)) {
-vdev->started = true;
-vdev->start_on_kick = false;
+virtio_set_started(vdev, true);
 }
 }
 }
@@ -1581,8 +1576,7 @@ void virtio_queue_notify(VirtIODevice *vdev, int n)
 vq->handle_output(vdev, vq);
 
 if (unlikely(vdev->start_on_kick)) {
-vdev->started = true;
-vdev->start_on_kick = false;
+virtio_set_started(vdev, true);
 }
 }
 }
@@ -2083,7 +2077,7 @@ int virtio_set_features(VirtIODevice *vdev, uint64_t val)
 }
 }
 
-if (!vdev->started &&
+if (!virtio_device_started(vdev, vdev->status) &&
 !virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
 vdev->start_on_kick = true;
 }
@@ -2238,7 +2232,7 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f, int 
version_id)
 }
 }
 
-if (!vdev->started &&
+if (!virtio_device_started(vdev, vdev->status) &&
 !virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
 vdev->start_on_kick = true;
 }
@@ -2306,7 +2300,7 @@ static void virtio_vmstate_change(void *opaque, int 
running, RunState state)
 VirtIODevice *vdev = opaque;
 BusState *qbus = qdev_get_parent_bus(DEVICE(vdev));
 VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
-bool backend_run = running && vdev->started;
+bool backend_run = running && virtio_device_started(vdev, vdev->status);
 vdev->vm_running = running;
 
 if (backend_run) {
@@ -2683,6 +2677,7 @@ static void virtio_device_instance_finalize(Object *obj)
 
 static Property virtio_properties[] = {
 DEFINE_VIRTIO_COMMON_FEATURES(VirtIODevice, host_features),
+DEFINE_PROP_BOOL("use-started", VirtIODevice, use_started, true),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 303242b3c2..b189788cb2 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -105,6 +105,7 @@ struct VirtIODevice
 uint16_t device_id;
 bool vm_running;
 bool broken; /* device in invalid state, needs reset */
+bool use_starte

[Qemu-devel] [PATCH v2 1/5] virtio: Set "start_on_kick" on virtio_set_features()

[elohimes]

From: Xie Yongji 

The guest feature is not set correctly on virtio_reset() and
virtio_init(). So we should not use it to set "start_on_kick" at that
point. This patch set "start_on_kick" on virtio_set_features() instead.

Fixes: badaf79cfdbd3 ("virtio: Introduce started flag to VirtioDevice")
Signed-off-by: Xie Yongji 
Reviewed-by: Greg Kurz 
---
 hw/virtio/virtio.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 07f4a64b48..6508b2faad 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -1214,8 +1214,7 @@ 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->start_on_kick = false;
 vdev->started = false;
 vdev->broken = false;
 vdev->guest_features = 0;
@@ -2069,14 +2068,22 @@ int virtio_set_features(VirtIODevice *vdev, uint64_t 
val)
 return -EINVAL;
 }
 ret = virtio_set_features_nocheck(vdev, val);
-if (!ret && virtio_vdev_has_feature(vdev, VIRTIO_RING_F_EVENT_IDX)) {
-/* VIRTIO_RING_F_EVENT_IDX changes the size of the caches.  */
-int i;
-for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
-if (vdev->vq[i].vring.num != 0) {
-virtio_init_region_cache(vdev, i);
+if (!ret) {
+if (virtio_vdev_has_feature(vdev, VIRTIO_RING_F_EVENT_IDX)) {
+/* VIRTIO_RING_F_EVENT_IDX changes the size of the caches.  */
+int i;
+for (i = 0; i < VIRTIO_QUEUE_MAX; i++) {
+if (vdev->vq[i].vring.num != 0) {
+virtio_init_region_cache(vdev, i);
+}
 }
 }
+
+if (!vdev->started &&
+virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1) &&
+!virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+vdev->start_on_kick = true;
+}
 }
 return ret;
 }
@@ -2228,6 +2235,12 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f, int 
version_id)
 }
 }
 
+if (!vdev->started &&
+virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1) &&
+!virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+vdev->start_on_kick = true;
+}
+
 rcu_read_lock();
 for (i = 0; i < num; i++) {
 if (vdev->vq[i].vring.desc) {
@@ -2330,8 +2343,7 @@ void virtio_init(VirtIODevice *vdev, const char *name,
 g_malloc0(sizeof(*vdev->vector_queues) * nvectors);
 }
 
-vdev->start_on_kick = (virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1) &&
-  !virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1));
+vdev->start_on_kick = false;
 vdev->started = false;
 vdev->device_id = device_id;
 vdev->status = 0;
-- 
2.17.1

[Qemu-devel] [PATCH v2 3/5] virtio: Make sure we get correct state of device on handle_aio_output()

[elohimes]

From: Xie Yongji 

We should set the flags: "start_on_kick" and "started" after we call
the kick functions (handle_aio_output() and handle_output()).

Signed-off-by: Xie Yongji 
---
 hw/virtio/virtio.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 6ec45d8f0a..3dc2f8c223 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -1575,11 +1575,11 @@ void virtio_queue_notify(VirtIODevice *vdev, int n)
 event_notifier_set(&vq->host_notifier);
 } else if (vq->handle_output) {
 vq->handle_output(vdev, vq);
-}
 
-if (unlikely(vdev->start_on_kick)) {
-vdev->started = true;
-vdev->start_on_kick = false;
+if (unlikely(vdev->start_on_kick)) {
+vdev->started = true;
+vdev->start_on_kick = false;
+}
 }
 }
 
-- 
2.17.1

Re: [Qemu-devel] [PATCH] linux-user: fix build with 5.2-rc2 kernel headers

[Laurent Vivier]

Le 04/06/2019 à 09:19, Christian Borntraeger a écrit :
> Since kernel commit 0768e17073dc527ccd ("net: socket: implement 64-bit
> timestamps") the linux kernel headers (those installed on the build
> system, not those that are synced to QEMU) will make qemu-user fail to
> build:
> 
> /root/rpmbuild/BUILD/qemu-4.0.50/linux-user/ioctls.h:222:9: error: 
> 'SIOCGSTAMP' undeclared here (not in a function); did you mean 'SIOCSRARP'?
>   222 |   IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
>   | ^~
> 
> Let us fix this by including  "linux/sockios.h" instead of relying on
> "sys/socket.h" providing those defines via an include chain.

I'm not sure it is as simple as this:
the value of SIOCGSTAMP depends on the size of struct timeval, and we
should use SIOCGSTAMP_OLD and SIOCGSTAMP_NEW to have the host and the
guest parts in sync.

Thanks,
Laurent
> 
> Cc: Riku Voipio 
> Cc: Laurent Vivier 
> Cc: Arnd Bergmann 
> Reported-by: Gerhard Stenzel 
> Signed-off-by: Christian Borntraeger 
> ---
>  linux-user/syscall.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index efa3ec2837..7332be9b06 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 

Re: [Qemu-devel] [PATCH] target/s390x: Use tcg_gen_gvec_bitsel

[David Hildenbrand]

On 03.06.19 23:59, Richard Henderson wrote:
> On 6/3/19 2:41 PM, David Hildenbrand wrote:
>>> -static void gen_sel_vec(unsigned vece, TCGv_vec d, TCGv_vec a, TCGv_vec b,
>>> -TCGv_vec c)
>>> -{
>>> -TCGv_vec t = tcg_temp_new_vec_matching(d);
>>> -
>>> -tcg_gen_andc_vec(vece, t, b, c);
>>> -tcg_gen_and_vec(vece, d, a, c);
>>> -tcg_gen_or_vec(vece, d, d, t);
>>> -tcg_temp_free_vec(t);
>>> -}
>>> -
>>
>> Comparing against tcg_gen_bitsel_i64()
>>
>> 1. a and c are switched
>> 2. b is _not_ switched (and() and andc() are switched)
> 
> Not quite.  {a,b,c} from your s390 implementation becomes {c,a,b} for tcg.
> 
> Running tests would show for sure; I guess you have those later in your vx
> patch set?

I only have a small selection of tests for now

84fa6254e4 tests/tcg: target/s390x: Test VECTOR ADD *
9e9a9e5246 tests/tcg: target/s390x: Test VECTOR UNPACK *
9d2b7184c6 tests/tcg: target/s390x: Test VECTOR PACK *
4872c1b6bd tests/tcg: target/s390x: Test VECTOR MERGE (HIGH|LOW)
914502d1d1 tests/tcg: target/s390x: Test VECTOR LOAD AND REPLICATE
7d01bbca17 tests/tcg: target/s390x: Test VECTOR GENERATE MASK
dc107ebdf7 tests/tcg: target/s390x: Test VECTOR GENERATE BYTE MASK
17212a732d tests/tcg: target/s390x: Test VECTOR LOAD GR FROM VR ELEMENT
f120e93c15 tests/tcg: target/s390x: Test VECTOR GATHER ELEMENT

But I just added a simple

6c43fe6a8c tests/tcg: target/s390x: Test VECTOR SELECT

That test confirmed that your implementation works correctly. :)

> 
>> Should I send this patch with the next s390x/tcg pull request?
> 
> Yes please.

I'll change the subject to "s390x/tcg: Use tcg_gen_gvec_bitsel for
VECTOR SELECT" if you don't object. Thanks!

> 
> 
> r~
> 


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v2 21/22] s390x/tcg: Allow linux-user to use vector instructions

[Laurent Vivier]

Le 03/06/2019 à 11:06, David Hildenbrand a écrit :
> Once we unlock S390_FEAT_VECTOR for TCG, we want linux-user to be
> able to make use of it.
> 
> Reviewed-by: Richard Henderson 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/cpu.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
> index b1df63d82c..6af1a1530f 100644
> --- a/target/s390x/cpu.c
> +++ b/target/s390x/cpu.c
> @@ -145,6 +145,9 @@ static void s390_cpu_full_reset(CPUState *s)
>  #if defined(CONFIG_USER_ONLY)
>  /* user mode should always be allowed to use the full FPU */
>  env->cregs[0] |= CR0_AFP;
> +if (s390_has_feat(S390_FEAT_VECTOR)) {
> +env->cregs[0] |= CR0_VECTOR;
> +}
>  #endif
>  
>  /* architectured initial value for Breaking-Event-Address register */
> 


Reviewed-by: Laurent Vivier 

Re: [Qemu-devel] [PULL 29/44] spapr/xive: introduce a VM state change handler

[Alexey Kardashevskiy]

On 29/05/2019 16:50, David Gibson wrote:
> From: Cédric Le Goater 
> 
> This handler is in charge of stabilizing the flow of event notifications
> in the XIVE controller before migrating a guest. This is a requirement
> before transferring the guest EQ pages to a destination.
> 
> When the VM is stopped, the handler sets the source PQs to PENDING to
> stop the flow of events and to possibly catch a triggered interrupt
> occuring while the VM is stopped. Their previous state is saved. The
> XIVE controller is then synced through KVM to flush any in-flight
> event notification and to stabilize the EQs. At this stage, the EQ
> pages are marked dirty to make sure the EQ pages are transferred if a
> migration sequence is in progress.
> 
> The previous configuration of the sources is restored when the VM
> resumes, after a migration or a stop. If an interrupt was queued while
> the VM was stopped, the handler simply generates the missing trigger.
> 
> Signed-off-by: Cédric Le Goater 
> Reviewed-by: David Gibson 
> Message-Id: <20190513084245.25755-6-...@kaod.org>
> Signed-off-by: David Gibson 

This one breaks my nvlink2 passthru setup. The host is v5.2-rc2.
v5.2-rc3 fixes it though so it is backward compatibility issue which we
care about to what degree here? I am forcing ic-mode=xive which is not
the default so I am not so sure.



aik@u1804kvm:~$ cat /proc/interrupts
   CPU0
 16:  0  XIVE-IPI   0 Edge  IPI
 21:  0  XIVE-IRQ 4096 Edge  RAS_EPOW
 22:  0  XIVE-IRQ 4097 Edge  RAS_HOTPLUG
257:  12372  XIVE-IRQ 4353 Edge  ibmvscsi
258:  0  XIVE-IRQ 4864 Edge  virtio0-config
259:   2157  XIVE-IRQ 4865 Edge  virtio0-input.0
260:  1  XIVE-IRQ 4866 Edge  virtio0-output.0
261:  0  XIVE-IRQ 4868 Edge  xhci_hcd
262:  0  XIVE-IRQ 4869 Edge  xhci_hcd
272:  1  XIVE-IRQ 4368 Edge  hvc_console
LOC:  10508   Local timer interrupts for timer event device
BCT:  0   Broadcast timer interrupts for timer event device
LOC:  0   Local timer interrupts for others
SPU:  5   Spurious interrupts
PMI:  0   Performance monitoring interrupts
MCE:  0   Machine check exceptions
NMI:  0   System Reset interrupts
DBL:  0   Doorbell interrupts


and 7bfc759c02b8 "spapr/xive: add state synchronization with KVM" works:

   CPU0
 16:  0  XIVE-IPI   0 Edge  IPI
 19:  0  XIVE-IRQ 4610 Level NPU Device
 20:  0  XIVE-IRQ 4611 Level NPU Device
 21:  0  XIVE-IRQ 4096 Edge  RAS_EPOW
 22:  0  XIVE-IRQ 4097 Edge  RAS_HOTPLUG
257:  11833  XIVE-IRQ 4353 Edge  ibmvscsi
258:  0  XIVE-IRQ 4864 Edge  virtio0-config
259:   1632  XIVE-IRQ 4865 Edge  virtio0-input.0
260:  1  XIVE-IRQ 4866 Edge  virtio0-output.0
261:  0  XIVE-IRQ 4868 Edge  xhci_hcd
262:  0  XIVE-IRQ 4869 Edge  xhci_hcd
263: 60  XIVE-IRQ 4867 Edge  nvidia
272:  0  XIVE-IRQ 4368 Edge  hvc_console
LOC:   2236   Local timer interrupts for timer event device
BCT:  0   Broadcast timer interrupts for timer event device
LOC:  0   Local timer interrupts for others
SPU:  2   Spurious interrupts
PMI:  0   Performance monitoring interrupts
MCE:  0   Machine check exceptions
NMI:  0   System Reset interrupts
DBL:  0   Doorbell interrupts



Here is the command line:

/home/aik/pbuild/qemu-aikrhel74alt-ppc64/ppc64-softmmu/qemu-system-ppc64 \
-nodefaults \
-chardev stdio,id=STDIO0,signal=off,mux=on \
-device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
-mon id=MON0,chardev=STDIO0,mode=readline -nographic -vga none \
-enable-kvm \
-device nec-usb-xhci,id=nec-usb-xhci0 -m 16G \
-netdev "user,id=USER0,hostfwd=tcp::2223-:22" \
-device "virtio-net-pci,id=vnet0,mac=C0:41:49:4b:00:00,netdev=USER0" \
img/u1804-64G-cuda10.1-418.67-swiotlb.qcow2 \
-machine pseries,cap-cfpc=broken,cap-htm=off,ic-mode=xive \
-device "vfio-pci,id=vfio0006_00_00_1,host=0006:00:00.1" \
-device "vfio-pci,id=vfio0006_00_00_0,host=0006:00:00.0" \
-device "vfio-pci,id=vfio0004_04_00_0,host=0004:04:00.0" \
-kernel ./vmldbg -append "root=/dev/sda2 console=hvc0 debug loglevel=8" \
-snapshot \
-smp 1,threads=1 -bios ./slof.bin \
-L /home/aik/t/qemu-ppc64-bios/ \
-trace events=qemu_trace_events -d guest_errors \
-chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.user2223.6_0_0_1 \
-mon chardev=SOCKET0,mode=control




> ---
>  hw/intc/spapr_xive_kvm.c| 96 -
>  include/hw/ppc/spapr_xive.h |  1 +
>  2 files changed, 96 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
> index 8dd4f96e0b..735577a6f8 100644
> --- a/hw/intc/spapr_xive_kvm.c
> +++ b/hw/intc/spapr_xive_kvm.c
> @@ -433,9 +433,100 @@ static void kvmppc_xive_get_queues(SpaprXive *xive, 
> Error **errp)
>  

[Qemu-devel] [Bug 1831225] Re: guest migration 100% cpu freeze bug

[Dion Bosschieter]

Is there a way that we can check that it indeed is the case that the clock 
jumped a bit, we can try to read some kernel variables.
We just got another hung guest's crash dump working, this vm also shows a weird 
uptime
DATE: Fri Dec 23 09:06:16 2603
UPTIME: 106752 days, 00:10:35

Till now we have only see this happening on guests with linux kernel
3.*.

Again dmesg shows nothing.

The only way this has yet happened was when the target hypervisor kernel was 
4.19.
So it seems that something changed over there, the only thing is it not quite a 
small diff ;) between 4.14 and 4.19. And because it only happens once every 
couple of thousand migrations with unknown conditions makes it a hard to bisect 
this.
Source hypervisor kernel could be 4.14 and 4.19.

If the clock did jump during the migration, is there something that we
could do about that on source/target hypervisor, with a libvirt xml
change, etc, to prevent it I mean.

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

Title:
  guest migration 100% cpu freeze bug

Status in QEMU:
  New

Bug description:
  # Investigate migration cpu hog(100%) bug

  I have some issues when migrating from kernel 4.14.63 running qemu 2.11.2 to 
kernel 4.19.43 running qemu 2.11.2.
  The hypervisors are running on debian jessie with libvirt v5.3.0.
  Linux, libvirt and qemu are all custom compiled.

  I migrated around 10.000 vms and every once in a while a vm is stuck
  at 100% cpu after what we can see right now is that the target
  hypervisor runs on linux 4.19.53. This happened with 4 vms so far. It
  is not that easy to debug, we found this out pretty quickly because we
  are running monitoring on frozen vms after migrations.

  Last year we were having the same "kind of" bug 
https://bugs.launchpad.net/qemu/+bug/177 when trying to upgrade qemu 2.6 to 
2.11.
  This bug was fixed after applying the following patch: 
http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg00820.html

  This patch is still applied as you can see because of the available pre_load 
var on the kvmclock_vmsd struct:
  (gdb) ptype kvmclock_vmsd
  type = const struct VMStateDescription {
  const char *name;
  int unmigratable;
  int version_id;
  int minimum_version_id;
  int minimum_version_id_old;
  MigrationPriority priority;
  LoadStateHandler *load_state_old;
  int (*pre_load)(void *);
  int (*post_load)(void *, int);
  int (*pre_save)(void *);
  _Bool (*needed)(void *);
  VMStateField *fields;
  const VMStateDescription **subsections;
  }

  I attached gdb to a vcpu thread of one stuck vm, and a bt showed the 
following info:
  Thread 4 (Thread 0x7f3a431a4700 (LWP 37799)):
  #0  0x7f3a576f5017 in ioctl () at ../sysdeps/unix/syscall-template.S:84
  #1  0x55d84d15de57 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55d84fca78d0, 
type=type@entry=44672) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:2050
  #2  0x55d84d15dfc6 in kvm_cpu_exec (cpu=cpu@entry=0x55d84fca78d0) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:1887
  #3  0x55d84d13ab64 in qemu_kvm_cpu_thread_fn (arg=0x55d84fca78d0) at 
/home/dbosschieter/src/qemu-pkg/src/cpus.c:1136
  #4  0x7f3a579ba4a4 in start_thread (arg=0x7f3a431a4700) at 
pthread_create.c:456
  #5  0x7f3a576fcd0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

  Thread 3 (Thread 0x7f3a439a5700 (LWP 37798)):
  #0  0x7f3a576f5017 in ioctl () at ../sysdeps/unix/syscall-template.S:84
  #1  0x55d84d15de57 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55d84fc5cbb0, 
type=type@entry=44672) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:2050
  #2  0x55d84d15dfc6 in kvm_cpu_exec (cpu=cpu@entry=0x55d84fc5cbb0) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:1887
  #3  0x55d84d13ab64 in qemu_kvm_cpu_thread_fn (arg=0x55d84fc5cbb0) at 
/home/dbosschieter/src/qemu-pkg/src/cpus.c:1136
  #4  0x7f3a579ba4a4 in start_thread (arg=0x7f3a439a5700) at 
pthread_create.c:456
  #5  0x7f3a576fcd0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

  The ioctl call is a ioctl(18, KVM_RUN and it looks like it is looping
  inside the vm itself.

  I saved the state of the VM (with `virsh save`) after I found it was hanging 
on its vcpu threads. Then I restored this vm on a test environment running the 
same kernel, QEMU and libvirt version). After the restore the VM still was 
haning at 100% cpu usage on all the vcpus.
  I tried to use the perf kvm guest option to trace the guest vm with a copy of 
the kernel, modules and kallsyms files from inside the guest vm and I got to 
the following perf stat:

   Event Total %Total CurAvg/s
   kvm_entry   5198993   23.1   277007
   kvm_exit   

Re: [Qemu-devel] [PULL 26/44] spapr/xive: add KVM support

[Cédric Le Goater]

On 04/06/2019 09:23, Alexey Kardashevskiy wrote:
> 
> 
> On 29/05/2019 16:49, David Gibson wrote:
>> From: Cédric Le Goater 
>>
>> This introduces a set of helpers when KVM is in use, which create the
>> KVM XIVE device, initialize the interrupt sources at a KVM level and
>> connect the interrupt presenters to the vCPU.
>>
>> They also handle the initialization of the TIMA and the source ESB
>> memory regions of the controller. These have a different type under
>> KVM. They are 'ram device' memory mappings, similarly to VFIO, exposed
>> to the guest and the associated VMAs on the host are populated
>> dynamically with the appropriate pages using a fault handler.
>>
>> Signed-off-by: Cédric Le Goater 
>> Reviewed-by: David Gibson 
>> Message-Id: <20190513084245.25755-3-...@kaod.org>
>> Signed-off-by: David Gibson 
> 
> 
> This one breaks my setup - it boots up to:
> 
> 
> ipr: IBM Power RAID SCSI Device Driver version: 2.6.4 (March 14, 2017)
> __vio_register_driver: driver ibmvscsi registering
> ibmvscsi 7101: SRP_VERSION: 16.a
> ibmvscsi 7101: Maximum ID: 64 Maximum LUN: 32 Maximum Channel: 3
> scsi host0: IBM POWER Virtual SCSI Adapter 1.5.9
> 
> 
> and hangs. Here is the command line:
> 
> 
> /home/aik/pbuild/qemu-aikrhel74alt-ppc64/ppc64-softmmu/qemu-system-ppc64 \
> -nodefaults \
> -chardev stdio,id=STDIO0,signal=off,mux=on \
> -device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
> -mon id=MON0,chardev=STDIO0,mode=readline -nographic -vga none \
> -enable-kvm \
> -device nec-usb-xhci,id=nec-usb-xhci0 -m 16G \
> -netdev "user,id=USER0,hostfwd=tcp::2223-:22" \
> -device "virtio-net-pci,id=vnet0,mac=C0:41:49:4b:00:00,netdev=USER0" \
> img/u1804-64G-cuda10.1-418.67-swiotlb.qcow2 \
> -machine pseries,cap-cfpc=broken,cap-htm=off,ic-mode=xive -snapshot \
> -smp 1,threads=1 -bios ./slof.bin \
> -L /home/aik/t/qemu-ppc64-bios/ \
> -trace events=qemu_trace_events -d guest_errors \
> -chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.user2223 \
> -mon chardev=SOCKET0,mode=control

At this level of patch 38afd772f802 ("spapr/xive: add KVM support"), I am
surprised this is even starting. 

The test in spapr_irq_init_xive() : 

/* KVM XIVE device not yet available */
if (kvm_enabled()) {
if (machine_kernel_irqchip_required(machine)) {
error_setg(errp, "kernel_irqchip requested. no KVM XIVE support");
return;
}
}

should fail. This is removed later in 0dc9f5f8496a ("spapr/xive: activate 
KVM support")

> The host kernel is v5.2-rc2. The next patch - 0c575703e487 "spapr/xive:
> add hcall support when under KVM" - fixes this though but the question
> is now if xive emulation in qemu still works (how do I verify it?).

kernel_irqchip=off should activate the QEMU XIVE device.

Are you testing bisection ?

C.

> 
> Any clues? Thanks,
> 
> 
>> ---
>>  hw/intc/Makefile.objs   |   1 +
>>  hw/intc/spapr_xive.c|  48 +++-
>>  hw/intc/spapr_xive_kvm.c| 237 
>>  hw/intc/xive.c  |  21 +++-
>>  hw/ppc/Kconfig  |   5 +
>>  hw/ppc/spapr_irq.c  |   6 +-
>>  include/hw/ppc/spapr_xive.h |  10 ++
>>  include/hw/ppc/xive.h   |  13 ++
>>  target/ppc/kvm.c|   7 ++
>>  target/ppc/kvm_ppc.h|   6 +
>>  10 files changed, 344 insertions(+), 10 deletions(-)
>>  create mode 100644 hw/intc/spapr_xive_kvm.c
>>
>> diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
>> index df712c3e6c..03019b9a03 100644
>> --- a/hw/intc/Makefile.objs
>> +++ b/hw/intc/Makefile.objs
>> @@ -39,6 +39,7 @@ obj-$(CONFIG_XICS_SPAPR) += xics_spapr.o
>>  obj-$(CONFIG_XICS_KVM) += xics_kvm.o
>>  obj-$(CONFIG_XIVE) += xive.o
>>  obj-$(CONFIG_XIVE_SPAPR) += spapr_xive.o
>> +obj-$(CONFIG_XIVE_KVM) += spapr_xive_kvm.o
>>  obj-$(CONFIG_POWERNV) += xics_pnv.o pnv_xive.o
>>  obj-$(CONFIG_ALLWINNER_A10_PIC) += allwinner-a10-pic.o
>>  obj-$(CONFIG_S390_FLIC) += s390_flic.o
>> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
>> index 62e13ac353..27632683e6 100644
>> --- a/hw/intc/spapr_xive.c
>> +++ b/hw/intc/spapr_xive.c
>> @@ -174,7 +174,7 @@ void spapr_xive_pic_print_info(SpaprXive *xive, Monitor 
>> *mon)
>>  }
>>  }
>>  
>> -static void spapr_xive_map_mmio(SpaprXive *xive)
>> +void spapr_xive_map_mmio(SpaprXive *xive)
>>  {
>>  sysbus_mmio_map(SYS_BUS_DEVICE(xive), 0, xive->vc_base);
>>  sysbus_mmio_map(SYS_BUS_DEVICE(xive), 1, xive->end_base);
>> @@ -251,6 +251,9 @@ static void spapr_xive_instance_init(Object *obj)
>>  object_initialize_child(obj, "end_source", &xive->end_source,
>>  sizeof(xive->end_source), TYPE_XIVE_END_SOURCE,
>>  &error_abort, NULL);
>> +
>> +/* Not connected to the KVM XIVE device */
>> +xive->fd = -1;
>>  }
>>  
>>  static void spapr_xive_realize(DeviceState *dev, Error **errp)
>> @@ -259,6 +262,7 @@ static void spapr_xive_realize(DeviceState *dev, Error 
>> **errp)
>>  XiveSource 

[Qemu-devel] [PING] [PATCH v0 0/3] add zstd cluster compression

[Denis Plotnikov]

On 28.05.2019 17:37, Denis Plotnikov wrote:
> The goal of the patch-set is to enable qcow2 to use zstd compression for
> clusters. ZSTD provides better (de)compression performance than currently
> used ZLIB. Using it will improve perforamnce (reduce compression time)
> when the compressed clusters is used, e.g backup scenarios.
> 
> Also, the patch-set extends qcow2 specification by adding compression_type
> feature. The feature enables adding ZSTD and another compression algorithms
> in the future.
> 
> Here is some measurements ZSTD vs ZLIB:
> 
> The test:
>  Test compresses and decompresses qemu qcow2 image with just
>  installed rhel-7.6 guest.
>  Image cluster size: 64K. Image on disk size: 2.2G
>  
>  The test was conducted with brd disk to reduce the influence
>  of disk subsystem to the test results.
>  The results is given in seconds.
>  
>  compress cmd:
>time ./qemu-img convert -O qcow2 -c -o compression_type=[zlib|zstd]
>src.img [zlib|zstd]_compressed.img
>  decompress cmd
>time ./qemu-img convert -O qcow2
>[zlib|zstd]_compressed.img uncompressed.img
> 
> 
> The results:
> compression   decompression
>   zlib   zstd   zlib zstd
>  
>  real 65.5   16.3 (-75 %)1.9  1.6 (-16 %)
>  user 65.0   15.85.3  2.5
>  sys   3.30.22.0  2.0
>  
>  Both ZLIB and ZSTD gave the same compression ratio: ~1.5
>  compressed image size in both cases: ~1.4G
> 
> Denis Plotnikov (3):
>qcow2: introduce compression type feature
>qcow2: add compression type processing
>qcow2: add zstd cluster compression
> 
>   block/qcow2.c | 240 --
>   block/qcow2.h |  29 +++--
>   configure |  26 +
>   docs/interop/qcow2.txt|  37 +-
>   include/block/block_int.h |   1 +
>   qapi/block-core.json  |  34 +-
>   6 files changed, 348 insertions(+), 19 deletions(-)
> 

-- 
Best,
Denis

[Qemu-devel] [PATCH] test: Fix make target check-report.tap

[Markus Armbruster]

Fix a fat-fingered invocation of tap-merge.pl in the recipe of target
check-report.tap.

Fixes: 9df43317b82 "test: replace gtester with a TAP driver"
Signed-off-by: Markus Armbruster 
---
 tests/Makefile.include | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 46a36c2c95..34df040583 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -904,7 +904,7 @@ check-report-unit.tap: $(check-unit-y)
 # Reports and overall runs
 
 check-report.tap: $(patsubst %,check-report-qtest-%.tap, $(QTEST_TARGETS)) 
check-report-unit.tap
-   $(call quiet-command,./scripts/tap-merge.py $^ > $@,"GEN","$@")
+   $(call quiet-command, cat $^ | scripts/tap-merge.pl >$@,"GEN","$@")
 
 # FPU Emulation tests (aka softfloat)
 #
-- 
2.21.0

[Qemu-devel] [Bug 1831225] Re: guest migration 100% cpu freeze bug

[Dion Bosschieter]

It seems like the patch is applied to the guests source kernel.

crash> clock_event_device
struct clock_event_device {
void (*event_handler)(struct clock_event_device *);
int (*set_next_event)(unsigned long, struct clock_event_device *);
int (*set_next_ktime)(ktime_t, struct clock_event_device *);
ktime_t next_event;
u64 max_delta_ns;
u64 min_delta_ns;
u32 mult;
u32 shift;
enum clock_event_mode mode;
unsigned int features;
unsigned long retries;
void (*broadcast)(const struct cpumask *);
void (*set_mode)(enum clock_event_mode, struct clock_event_device *);
void (*suspend)(struct clock_event_device *);
void (*resume)(struct clock_event_device *);
unsigned long min_delta_ticks;
unsigned long max_delta_ticks;
const char *name;
int rating;
int irq;
const struct cpumask *cpumask;
struct list_head list;
struct module *owner;
}
SIZE: 0xc0
crash> clockevents_program_min_delta
clockevents_program_min_delta = $2 = 
 {int (struct clock_event_device *)} 0x810daa20 


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

Title:
  guest migration 100% cpu freeze bug

Status in QEMU:
  New

Bug description:
  # Investigate migration cpu hog(100%) bug

  I have some issues when migrating from kernel 4.14.63 running qemu 2.11.2 to 
kernel 4.19.43 running qemu 2.11.2.
  The hypervisors are running on debian jessie with libvirt v5.3.0.
  Linux, libvirt and qemu are all custom compiled.

  I migrated around 10.000 vms and every once in a while a vm is stuck
  at 100% cpu after what we can see right now is that the target
  hypervisor runs on linux 4.19.53. This happened with 4 vms so far. It
  is not that easy to debug, we found this out pretty quickly because we
  are running monitoring on frozen vms after migrations.

  Last year we were having the same "kind of" bug 
https://bugs.launchpad.net/qemu/+bug/177 when trying to upgrade qemu 2.6 to 
2.11.
  This bug was fixed after applying the following patch: 
http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg00820.html

  This patch is still applied as you can see because of the available pre_load 
var on the kvmclock_vmsd struct:
  (gdb) ptype kvmclock_vmsd
  type = const struct VMStateDescription {
  const char *name;
  int unmigratable;
  int version_id;
  int minimum_version_id;
  int minimum_version_id_old;
  MigrationPriority priority;
  LoadStateHandler *load_state_old;
  int (*pre_load)(void *);
  int (*post_load)(void *, int);
  int (*pre_save)(void *);
  _Bool (*needed)(void *);
  VMStateField *fields;
  const VMStateDescription **subsections;
  }

  I attached gdb to a vcpu thread of one stuck vm, and a bt showed the 
following info:
  Thread 4 (Thread 0x7f3a431a4700 (LWP 37799)):
  #0  0x7f3a576f5017 in ioctl () at ../sysdeps/unix/syscall-template.S:84
  #1  0x55d84d15de57 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55d84fca78d0, 
type=type@entry=44672) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:2050
  #2  0x55d84d15dfc6 in kvm_cpu_exec (cpu=cpu@entry=0x55d84fca78d0) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:1887
  #3  0x55d84d13ab64 in qemu_kvm_cpu_thread_fn (arg=0x55d84fca78d0) at 
/home/dbosschieter/src/qemu-pkg/src/cpus.c:1136
  #4  0x7f3a579ba4a4 in start_thread (arg=0x7f3a431a4700) at 
pthread_create.c:456
  #5  0x7f3a576fcd0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

  Thread 3 (Thread 0x7f3a439a5700 (LWP 37798)):
  #0  0x7f3a576f5017 in ioctl () at ../sysdeps/unix/syscall-template.S:84
  #1  0x55d84d15de57 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55d84fc5cbb0, 
type=type@entry=44672) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:2050
  #2  0x55d84d15dfc6 in kvm_cpu_exec (cpu=cpu@entry=0x55d84fc5cbb0) at 
/home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:1887
  #3  0x55d84d13ab64 in qemu_kvm_cpu_thread_fn (arg=0x55d84fc5cbb0) at 
/home/dbosschieter/src/qemu-pkg/src/cpus.c:1136
  #4  0x7f3a579ba4a4 in start_thread (arg=0x7f3a439a5700) at 
pthread_create.c:456
  #5  0x7f3a576fcd0f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

  The ioctl call is a ioctl(18, KVM_RUN and it looks like it is looping
  inside the vm itself.

  I saved the state of the VM (with `virsh save`) after I found it was hanging 
on its vcpu threads. Then I restored this vm on a test environment running the 
same kernel, QEMU and libvirt version). After the restore the VM still was 
haning at 100% cpu usage on all the vcpus.
  I tried to use the perf kvm guest option to trace the guest vm with a copy of 
the kernel, modules and kallsyms files from inside the guest vm and I got to 
the following perf stat:

   Event Total %T

Re: [Qemu-devel] [PULL 26/44] spapr/xive: add KVM support

[Greg Kurz]

On Tue, 4 Jun 2019 09:54:59 +0200
Cédric Le Goater  wrote:

> On 04/06/2019 09:23, Alexey Kardashevskiy wrote:
> > 
> > 
> > On 29/05/2019 16:49, David Gibson wrote:  
> >> From: Cédric Le Goater 
> >>
> >> This introduces a set of helpers when KVM is in use, which create the
> >> KVM XIVE device, initialize the interrupt sources at a KVM level and
> >> connect the interrupt presenters to the vCPU.
> >>
> >> They also handle the initialization of the TIMA and the source ESB
> >> memory regions of the controller. These have a different type under
> >> KVM. They are 'ram device' memory mappings, similarly to VFIO, exposed
> >> to the guest and the associated VMAs on the host are populated
> >> dynamically with the appropriate pages using a fault handler.
> >>
> >> Signed-off-by: Cédric Le Goater 
> >> Reviewed-by: David Gibson 
> >> Message-Id: <20190513084245.25755-3-...@kaod.org>
> >> Signed-off-by: David Gibson   
> > 
> > 
> > This one breaks my setup - it boots up to:
> > 
> > 
> > ipr: IBM Power RAID SCSI Device Driver version: 2.6.4 (March 14, 2017)
> > __vio_register_driver: driver ibmvscsi registering
> > ibmvscsi 7101: SRP_VERSION: 16.a
> > ibmvscsi 7101: Maximum ID: 64 Maximum LUN: 32 Maximum Channel: 3
> > scsi host0: IBM POWER Virtual SCSI Adapter 1.5.9
> > 
> > 
> > and hangs. Here is the command line:
> > 
> > 
> > /home/aik/pbuild/qemu-aikrhel74alt-ppc64/ppc64-softmmu/qemu-system-ppc64 \
> > -nodefaults \
> > -chardev stdio,id=STDIO0,signal=off,mux=on \
> > -device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
> > -mon id=MON0,chardev=STDIO0,mode=readline -nographic -vga none \
> > -enable-kvm \
> > -device nec-usb-xhci,id=nec-usb-xhci0 -m 16G \
> > -netdev "user,id=USER0,hostfwd=tcp::2223-:22" \
> > -device "virtio-net-pci,id=vnet0,mac=C0:41:49:4b:00:00,netdev=USER0" \
> > img/u1804-64G-cuda10.1-418.67-swiotlb.qcow2 \
> > -machine pseries,cap-cfpc=broken,cap-htm=off,ic-mode=xive -snapshot \
> > -smp 1,threads=1 -bios ./slof.bin \
> > -L /home/aik/t/qemu-ppc64-bios/ \
> > -trace events=qemu_trace_events -d guest_errors \
> > -chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.user2223 \
> > -mon chardev=SOCKET0,mode=control  
> 
> At this level of patch 38afd772f802 ("spapr/xive: add KVM support"), I am
> surprised this is even starting. 
> 
> The test in spapr_irq_init_xive() : 
> 
> /* KVM XIVE device not yet available */
> if (kvm_enabled()) {
> if (machine_kernel_irqchip_required(machine)) {

The problem is that machine_kernel_irqchip_required(machine) returns false
if kernel_irqchip wasn't specified on the command line, which is the case
here. Maybe machine_kernel_irqchip_allowed() would have make more sense,
but...

> error_setg(errp, "kernel_irqchip requested. no KVM XIVE support");
> return;
> }
> }
> 
> should fail. This is removed later in 0dc9f5f8496a ("spapr/xive: activate 
> KVM support")
> 

... do we really care since this code gets removed later ?

> > The host kernel is v5.2-rc2. The next patch - 0c575703e487 "spapr/xive:
> > add hcall support when under KVM" - fixes this though but the question
> > is now if xive emulation in qemu still works (how do I verify it?).  
> 
> kernel_irqchip=off should activate the QEMU XIVE device.
> 
> Are you testing bisection ?
> 
> C.
> 
> > 
> > Any clues? Thanks,
> > 
> >   
> >> ---
> >>  hw/intc/Makefile.objs   |   1 +
> >>  hw/intc/spapr_xive.c|  48 +++-
> >>  hw/intc/spapr_xive_kvm.c| 237 
> >>  hw/intc/xive.c  |  21 +++-
> >>  hw/ppc/Kconfig  |   5 +
> >>  hw/ppc/spapr_irq.c  |   6 +-
> >>  include/hw/ppc/spapr_xive.h |  10 ++
> >>  include/hw/ppc/xive.h   |  13 ++
> >>  target/ppc/kvm.c|   7 ++
> >>  target/ppc/kvm_ppc.h|   6 +
> >>  10 files changed, 344 insertions(+), 10 deletions(-)
> >>  create mode 100644 hw/intc/spapr_xive_kvm.c
> >>
> >> diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
> >> index df712c3e6c..03019b9a03 100644
> >> --- a/hw/intc/Makefile.objs
> >> +++ b/hw/intc/Makefile.objs
> >> @@ -39,6 +39,7 @@ obj-$(CONFIG_XICS_SPAPR) += xics_spapr.o
> >>  obj-$(CONFIG_XICS_KVM) += xics_kvm.o
> >>  obj-$(CONFIG_XIVE) += xive.o
> >>  obj-$(CONFIG_XIVE_SPAPR) += spapr_xive.o
> >> +obj-$(CONFIG_XIVE_KVM) += spapr_xive_kvm.o
> >>  obj-$(CONFIG_POWERNV) += xics_pnv.o pnv_xive.o
> >>  obj-$(CONFIG_ALLWINNER_A10_PIC) += allwinner-a10-pic.o
> >>  obj-$(CONFIG_S390_FLIC) += s390_flic.o
> >> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> >> index 62e13ac353..27632683e6 100644
> >> --- a/hw/intc/spapr_xive.c
> >> +++ b/hw/intc/spapr_xive.c
> >> @@ -174,7 +174,7 @@ void spapr_xive_pic_print_info(SpaprXive *xive, 
> >> Monitor *mon)
> >>  }
> >>  }
> >>  
> >> -static void spapr_xive_map_mmio(SpaprXive *xive)
> >> +void spapr_xive_map_mmio(SpaprXive *xive)
> >>  {
> >>  sysbus_mmio_map(SYS_BUS_DEVICE(xive), 0, xive->vc_base);
> >>

Re: [Qemu-devel] [PATCH] test: Fix make target check-report.tap

[Philippe Mathieu-Daudé]

On 6/4/19 10:00 AM, Markus Armbruster wrote:
> Fix a fat-fingered invocation of tap-merge.pl in the recipe of target
> check-report.tap.
> 
> Fixes: 9df43317b82 "test: replace gtester with a TAP driver"
> Signed-off-by: Markus Armbruster 
> ---
>  tests/Makefile.include | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index 46a36c2c95..34df040583 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -904,7 +904,7 @@ check-report-unit.tap: $(check-unit-y)
>  # Reports and overall runs
>  
>  check-report.tap: $(patsubst %,check-report-qtest-%.tap, $(QTEST_TARGETS)) 
> check-report-unit.tap
> - $(call quiet-command,./scripts/tap-merge.py $^ > $@,"GEN","$@")
> + $(call quiet-command, cat $^ | scripts/tap-merge.pl >$@,"GEN","$@")

Paolo, did you intend to submit a new tap-merge.py script in commit
9df43317b82?

>  
>  # FPU Emulation tests (aka softfloat)
>  #
> 

Re: [Qemu-devel] [PULL 29/44] spapr/xive: introduce a VM state change handler

[Cédric Le Goater]

On 04/06/2019 09:49, Alexey Kardashevskiy wrote:
> 
> 
> On 29/05/2019 16:50, David Gibson wrote:
>> From: Cédric Le Goater 
>>
>> This handler is in charge of stabilizing the flow of event notifications
>> in the XIVE controller before migrating a guest. This is a requirement
>> before transferring the guest EQ pages to a destination.
>>
>> When the VM is stopped, the handler sets the source PQs to PENDING to
>> stop the flow of events and to possibly catch a triggered interrupt
>> occuring while the VM is stopped. Their previous state is saved. The
>> XIVE controller is then synced through KVM to flush any in-flight
>> event notification and to stabilize the EQs. At this stage, the EQ
>> pages are marked dirty to make sure the EQ pages are transferred if a
>> migration sequence is in progress.
>>
>> The previous configuration of the sources is restored when the VM
>> resumes, after a migration or a stop. If an interrupt was queued while
>> the VM was stopped, the handler simply generates the missing trigger.
>>
>> Signed-off-by: Cédric Le Goater 
>> Reviewed-by: David Gibson 
>> Message-Id: <20190513084245.25755-6-...@kaod.org>
>> Signed-off-by: David Gibson 
> 
> This one breaks my nvlink2 passthru setup. The host is v5.2-rc2.
> v5.2-rc3 fixes it though so it is backward compatibility issue which we
> care about to what degree here? 

v5.2-rc2 had an ugly bug impacting passthru under some VM configuration,
XIVE + single CPU. See :

bcaa3110d584 ("KVM: PPC: Book3S HV: XIVE: Fix page offset when clearing 
ESB pages")

passthru also had a serious issue impacting the XICS-over-XIVE and the 
XIVE KVM devices :   

ef9740204051 ("KVM: PPC: Book3S HV: XIVE: Do not clear IRQ data of 
passthrough interrupts")

You need an v5.2-rc3 ! 

> I am forcing ic-mode=xive which is not the default so I am not so sure.

It should be OK.

C. 

> 
> 
> 
> aik@u1804kvm:~$ cat /proc/interrupts
>CPU0
>  16:  0  XIVE-IPI   0 Edge  IPI
>  21:  0  XIVE-IRQ 4096 Edge  RAS_EPOW
>  22:  0  XIVE-IRQ 4097 Edge  RAS_HOTPLUG
> 257:  12372  XIVE-IRQ 4353 Edge  ibmvscsi
> 258:  0  XIVE-IRQ 4864 Edge  virtio0-config
> 259:   2157  XIVE-IRQ 4865 Edge  virtio0-input.0
> 260:  1  XIVE-IRQ 4866 Edge  virtio0-output.0
> 261:  0  XIVE-IRQ 4868 Edge  xhci_hcd
> 262:  0  XIVE-IRQ 4869 Edge  xhci_hcd
> 272:  1  XIVE-IRQ 4368 Edge  hvc_console
> LOC:  10508   Local timer interrupts for timer event device
> BCT:  0   Broadcast timer interrupts for timer event device
> LOC:  0   Local timer interrupts for others
> SPU:  5   Spurious interrupts
> PMI:  0   Performance monitoring interrupts
> MCE:  0   Machine check exceptions
> NMI:  0   System Reset interrupts
> DBL:  0   Doorbell interrupts
> 
> 
> and 7bfc759c02b8 "spapr/xive: add state synchronization with KVM" works:
> 
>CPU0
>  16:  0  XIVE-IPI   0 Edge  IPI
>  19:  0  XIVE-IRQ 4610 Level NPU Device
>  20:  0  XIVE-IRQ 4611 Level NPU Device
>  21:  0  XIVE-IRQ 4096 Edge  RAS_EPOW
>  22:  0  XIVE-IRQ 4097 Edge  RAS_HOTPLUG
> 257:  11833  XIVE-IRQ 4353 Edge  ibmvscsi
> 258:  0  XIVE-IRQ 4864 Edge  virtio0-config
> 259:   1632  XIVE-IRQ 4865 Edge  virtio0-input.0
> 260:  1  XIVE-IRQ 4866 Edge  virtio0-output.0
> 261:  0  XIVE-IRQ 4868 Edge  xhci_hcd
> 262:  0  XIVE-IRQ 4869 Edge  xhci_hcd
> 263: 60  XIVE-IRQ 4867 Edge  nvidia
> 272:  0  XIVE-IRQ 4368 Edge  hvc_console
> LOC:   2236   Local timer interrupts for timer event device
> BCT:  0   Broadcast timer interrupts for timer event device
> LOC:  0   Local timer interrupts for others
> SPU:  2   Spurious interrupts
> PMI:  0   Performance monitoring interrupts
> MCE:  0   Machine check exceptions
> NMI:  0   System Reset interrupts
> DBL:  0   Doorbell interrupts
> 
> 
> 
> Here is the command line:
> 
> /home/aik/pbuild/qemu-aikrhel74alt-ppc64/ppc64-softmmu/qemu-system-ppc64 \
> -nodefaults \
> -chardev stdio,id=STDIO0,signal=off,mux=on \
> -device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
> -mon id=MON0,chardev=STDIO0,mode=readline -nographic -vga none \
> -enable-kvm \
> -device nec-usb-xhci,id=nec-usb-xhci0 -m 16G \
> -netdev "user,id=USER0,hostfwd=tcp::2223-:22" \
> -device "virtio-net-pci,id=vnet0,mac=C0:41:49:4b:00:00,netdev=USER0" \
> img/u1804-64G-cuda10.1-418.67-swiotlb.qcow2 \
> -machine pseries,cap-cfpc=broken,cap-htm=off,ic-mode=xive \
> -device "vfio-pci,id=vfio0006_00_00_1,host=0006:00:00.1" \
> -device "vfio-pci,id=vfio0006_00_00_0,host=0006:00:00.0" \
> -device "vfio-pci,id=vfio0004_04_00_0,host=0004:04:00.0" \
> -kernel ./vmldbg -append "root=/dev/sda2 console=hvc0 debug loglevel=8" \
> -snapshot \
> -smp 1,threads=1 -bios ./sl

Re: [Qemu-devel] [PATCH v1 2/2] s390x/tcg: Store only the necessary amount of doublewords for STFLE

[David Hildenbrand]

On 03.06.19 16:39, Stefan Liebler wrote:
> On 6/3/19 12:45 PM, David Hildenbrand wrote:
>> On 03.06.19 12:38, Stefan Liebler wrote:
>>> On 5/31/19 4:56 PM, David Hildenbrand wrote:
 The PoP (z14, 7-382) says:
   Doublewords to the right of the doubleword in which the
   highest-numbered facility bit is assigned for a model
   may or may not be stored.

 However, stack protection in certain binaries can't deal with that.
 "gzip" example code:

 f1b4:   a7 08 00 03 lhi %r0,3
 f1b8:   b2 b0 f0 a0 stfle   160(%r15)
 f1bc:   e3 20 f0 b2 00 90   llgc%r2,178(%r15)
 f1c2:   c0 2b 00 00 00 01   nilf%r2,1
 f1c8:   b2 4f 00 10 ear %r1,%a0
 f1cc:   b9 14 00 22 lgfr%r2,%r2
 f1d0:   eb 11 00 20 00 0d   sllg%r1,%r1,32
 f1d6:   b2 4f 00 11 ear %r1,%a1
 f1da:   d5 07 f0 b8 10 28   clc 184(8,%r15),40(%r1)
 f1e0:   a7 74 00 06 jne f1ec 
 f1e4:   eb ef f1 30 00 04   lmg %r14,%r15,304(%r15)
 f1ea:   07 fe   br  %r14
 f1ec:   c0 e5 ff ff 9d 6e   brasl   %r14,2cc8 
 <__stack_chk_fail@plt>

 In QEMU, we currently have:
   max_bytes = 24
 the code asks for (3 + 1) doublewords == 32 bytes.

 If we write 32 bytes instead of only 24, and return "2 + 1" doublewords
 ("one less than the number of doulewords needed to contain all of the
facility bits"), the example code detects a stack corruption.

 In my opinion, the code is wrong. However, it seems to work fine on
 real machines. So let's limit storing to the minimum of the requested
 and the maximum doublewords.
>>> Hi David,
>>>
>>> Thanks for catching this. I've reported the "gzip" example to Ilya and
>>> indeed, r0 is setup too large. He will fix it in gzip.
>>>
>>> You've mentioned, that this is detected in certain binaries.
>>> Can you please share those occurrences.
>>
>> Hi Stafan,
>>
>> thanks for your reply.
>>
>> I didn't track all occurrences, it *could* be that it was only gzip in
>> the background making other processes fail.
>>
>> For example, the systemd "vitual console setup" unit failed, too, which
>> was fixed by this change.
> At least "objdump -d /usr/lib/systemd/systemd-vconsole-setup" does not 
> contain the stfle instruction, but "ldd 
> /usr/lib/systemd/systemd-vconsole-setup" is showing libz.so which could 
> also contain Ilya's patches with the stfle instruction (I assume there 
> is the same bug as in gzip). But I have no idea if libz is really called.
>>
>> I also remember, seeing segfaults in rpmbuild, for example. They only
>> "changed" with this fix - I m still chasing different errors. :)
> The same applies for rpmbuild.
>>
>> You mentioned "He will fix it in gzip", so I assume this is a gzip issue
>> and not a gcc/glibc/whatever toolchain issue?
>>
> Yes, this is a gzip bug. r0 was initialized with:
> (sizeof(array-on-stack) / 8)
> instead of:
> (sizeof(array-on-stack) / 8) - 1
> 
> Ilya will fix it in gzip and zlib.
> @Ilya: Please correct me if I'm wrong.
> 

Makes sense, thanks for the explanation!

-- 

Thanks,

David / dhildenb

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

[Klaus Birkelund]

On Mon, Jun 03, 2019 at 09:30:53AM -0600, Heitke, Kenneth wrote:
> 
> 
> On 6/3/2019 5:14 AM, Kevin Wolf wrote:
> > Am 28.05.2019 um 08:18 hat Klaus Birkelund geschrieben:
> > > On Mon, May 20, 2019 at 11:40:30AM -0600, Kenneth Heitke wrote:
> > > > Signed-off-by: Kenneth Heitke 
> > 
> > > > diff --git a/hw/block/nvme.h b/hw/block/nvme.h
> > > > index 56c9d4b4b1..d7277e72b7 100644
> > > > --- a/hw/block/nvme.h
> > > > +++ b/hw/block/nvme.h
> > > > @@ -69,6 +69,7 @@ typedef struct NvmeCtrl {
> > > >   uint16_tmax_prp_ents;
> > > >   uint16_tcqe_size;
> > > >   uint16_tsqe_size;
> > > > +uint16_toncs;
> > > 
> > > Looks like this unused member snuck its way into the patch. But I see no
> > > harm in it being there.
> > 
> > Good catch. I'll just remove it again from my branch.
> > 
> > > > +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);
> > 
> > Here I wonder why we use QEMU_CLOCK_REALTIME in a device emulation.
> > Wouldn't QEMU_CLOCK_VIRTUAL make more sense?
> > 
> 
> QEMU_CLOCK_VIRTUAL probably would make more sense. When I was reading
> through the differences I wasn't really sure what to pick. iven that this is
> the time within the device's context, the virtual time seems more correct.
> 
 
I thought about this too when I reviewed, but came to the conclusion
that REALTIME was correct. The timestamp is basically a value that the
host stores in the controller. When the host uses Get Features to get
the the current time it would expect it to match the progression for its
own wall clockright? If I understand REALTIME vs VIRTUAL correctly,
using VIRTUAL, it would go way out of sync.

Klaus

Re: [Qemu-devel] [PATCH] test: Fix make target check-report.tap

[Paolo Bonzini]

On 04/06/19 10:09, Philippe Mathieu-Daudé wrote:
>>  check-report.tap: $(patsubst %,check-report-qtest-%.tap, $(QTEST_TARGETS)) 
>> check-report-unit.tap
>> -$(call quiet-command,./scripts/tap-merge.py $^ > $@,"GEN","$@")
>> +$(call quiet-command, cat $^ | scripts/tap-merge.pl >$@,"GEN","$@")
> Paolo, did you intend to submit a new tap-merge.py script in commit
> 9df43317b82?
> 

No, it's really just y vs l.

Reviewed-by: Paolo Bonzini 
Cc: qemu-triv...@nongnu.org

Paolo

Re: [Qemu-devel] [PATCH v3] migratioin/ram: leave RAMBlock->bmap blank on allocating

[Wei Yang]

On Tue, Jun 04, 2019 at 03:06:14PM +0800, Peter Xu wrote:
>On Tue, Jun 04, 2019 at 02:17:27PM +0800, Wei Yang wrote:
>> During migration, we would sync bitmap from ram_list.dirty_memory to
>> RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap().
>> 
>> Since we set RAMBlock.bmap and ram_list.dirty_memory both to all 1, this
>> means at the first round this sync is meaningless and is a duplicated
>> work.
>> 
>> Leaving RAMBlock->bmap blank on allocating would have a side effect on
>> migration_dirty_pages, since it is calculated from the result of
>> cpu_physical_memory_sync_dirty_bitmap(). To keep it right, we need to
>> set migration_dirty_pages to 0 in ram_state_init().
>> 
>> Signed-off-by: Wei Yang 
>> Reviewed-by: Dr. David Alan Gilbert 
>
>Thanks for updating the comments.
>

My pleasure :-)

>Acked-by: Peter Xu 
>
>-- 
>Peter Xu

-- 
Wei Yang
Help you, Help me

Re: [Qemu-devel] qgraph

[Natalia Fursova]

ping

 

 

Best regards, 

Natalia

 

From: Наталья Фурсова [mailto:natalia.furs...@ispras.ru] 
Sent: Wednesday, May 29, 2019 2:57 PM
To: 'qemu-devel@nongnu.org'; 'pbonz...@redhat.com'; Паша
(pavel.dovga...@ispras.ru)
Subject: qgraph

 

Hello, Paolo!

 

We develop GUI for Qemu and want to implement graphical interface for
configuring the device tree. To do this we need to detect list of the
devices supported by any specific platform.

Then we use this tree for command line generation.

 

Existing qmp commands don't supply enough information to build the tree.
They miss bus and interface data.

 

There is something called 'qgraph' in Qemu. It looks similar to data
structures in our GUI tool.

 

Tell me please, do you have a plan on improving this interface? We found the
following hardcoded lines in the tests:

qos_node_consumes("megasas", "pci-bus", &opts);

qos_node_produces("megasas", "pci-device");

 

And we wanted to extend QMP to query this kind of information.

 

 

Best regards, 

Natalia

 

Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/2] blockdev: Overlays are not snapshots

[Alberto Garcia]

On Mon 03 Jun 2019 10:22:34 PM CEST, Max Reitz wrote:
> QEMU’s always been confused over what a snapshot is: Is it the overlay?
> Is it the backing image?
>
> Confusion is rarely a good thing.  I can’t think of any objective reason
> why the overlay would be a snapshot.  A snapshot is something that does
> not change over time; the overlay does.
>
> (I suppose historically the reason is that “Taking an overlay” makes no
> sense, so the operations are called “Taking a snapshot”.  Somehow, this
> meaning carried over to the new file that is created during that
> operation; if “Creating a snapshot” creates a file, that file must be
> the snapshot, right?  Well, no, it isn’t.)
>
> Let’s fix this as best as we can.  Better Nate than lever.

Reviewed-by: Alberto Garcia 

Berto

[Qemu-devel] virtual machine cpu soft lock when qemu attach disk

[l00284672]

Hi,  I found a problem that virtual machine cpu soft lock when I attach 
a disk to the vm in the case that


backend storage network has a large delay or IO pressure is too large.

1) The disk xml which I attached is:

    
  
  
  
  
  
  
    

2) The bt of qemu main thread:

#0 0x9d78402c in pread64 () from /lib64/libpthread.so.0
#1 0xce3357d8 in pread64 (__offset=0, __nbytes=4096, 
__buf=0xd47a5200, __fd=202) at /usr/include/bits/unistd.h:99
#2 raw_is_io_aligned (fd=fd@entry=202, buf=buf@entry=0xd47a5200, 
len=len@entry=4096) at block/raw_posix.c:294
#3 0xce33597c in raw_probe_alignment 
(bs=bs@entry=0xd32ea920, fd=202, errp=errp@entry=0xfef7a330) at 
block/raw_posix.c:349
#4 0xce335a48 in raw_refresh_limits (bs=0xd32ea920, 
errp=0xfef7a330) at block/raw_posix.c:811
#5 0xce3404b0 in bdrv_refresh_limits (bs=0xd32ea920, 
errp=0xfef7a330, errp@entry=0xfef7a360) at block/io.c:122
#6 0xce340504 in bdrv_refresh_limits 
(bs=bs@entry=0xd09ce800, errp=errp@entry=0xfef7a3b0) at 
block/io.c:97
#7 0xce2eb9f0 in bdrv_open_common (bs=bs@entry=0xd09ce800, 
file=file@entry=0xd0e89800, options=, 
errp=errp@entry=0xfef7a450)

at block.c:1194
#8 0xce2eedec in bdrv_open_inherit (filename=, 
filename@entry=0xd25f92d0 
"/dev/mapper/36384c4f100630193359db7a8011d",
reference=reference@entry=0x0, options=, 
options@entry=0xd3d0f4b0, flags=, flags@entry=128, 
parent=parent@entry=0x0,
child_role=child_role@entry=0x0, errp=errp@entry=0xfef7a710) at 
block.c:1895
#9 0xce2ef510 in bdrv_open 
(filename=filename@entry=0xd25f92d0 
"/dev/mapper/36384c4f100630193359db7a8011d", 
reference=reference@entry=0x0,
options=options@entry=0xd3d0f4b0, flags=flags@entry=128, 
errp=errp@entry=0xfef7a710) at block.c:1979
#10 0xce331ef0 in blk_new_open 
(filename=filename@entry=0xd25f92d0 
"/dev/mapper/36384c4f100630193359db7a8011d", 
reference=reference@entry=0x0,
options=options@entry=0xd3d0f4b0, flags=128, 
errp=errp@entry=0xfef7a710) at block/block_backend.c:213
#11 0xce0da1f4 in blockdev_init (file=file@entry=0xd25f92d0 
"/dev/mapper/36384c4f100630193359db7a8011d", 
bs_opts=bs_opts@entry=0xd3d0f4b0,

errp=errp@entry=0xfef7a710) at blockdev.c:603
#12 0xce0dc478 in drive_new 
(all_opts=all_opts@entry=0xd4dc31d0, block_default_type=out>) at blockdev.c:1116

#13 0xce0e3ee0 in add_init_drive (
optstr=optstr@entry=0xd0872ec0 
"file=/dev/mapper/36384c4f100630193359db7a8011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native")

at device_hotplug.c:46
#14 0xce0e3f78 in hmp_drive_add (mon=0xfef7a810, 
qdict=0xd0c8f000) at device_hotplug.c:67
#15 0xcdf7d688 in handle_hmp_command (mon=0xfef7a810, 
cmdline=) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:3199

#16 0xcdf7d778 in qmp_human_monitor_command (
command_line=0xcfc8e3c0 "drive_add dummy 
file=/dev/mapper/36384c4f100630193359db7a8011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native", 

has_cpu_index=false, cpu_index=0, errp=errp@entry=0xfef7a968) at 
/usr/src/debug/qemu-kvm-2.8.1/monitor.c:660
#17 0xce0fdb30 in qmp_marshal_human_monitor_command 
(args=, ret=0xfef7a9e0, errp=0xfef7a9d8) at 
qmp-marshal.c:2223
#18 0xce3b6ad0 in do_qmp_dispatch (request=, 
errp=0xfef7aa20, errp@entry=0xfef7aa40) at qapi/qmp_dispatch.c:115
#19 0xce3b6d58 in qmp_dispatch (request=) at 
qapi/qmp_dispatch.c:142
#20 0xcdf79398 in handle_qmp_command (parser=, 
tokens=) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:4010
#21 0xce3bd6c0 in json_message_process_token 
(lexer=0xcf834c80, input=, type=JSON_RCURLY, x=214, 
y=274) at qobject/json_streamer.c:105
#22 0xce3f3d4c in json_lexer_feed_char 
(lexer=lexer@entry=0xcf834c80, ch=, 
flush=flush@entry=false) at qobject/json_lexer.c:319
#23 0xce3f3e6c in json_lexer_feed (lexer=0xcf834c80, 
buffer=, size=) at qobject/json_lexer.c:369
#24 0xcdf77c64 in monitor_qmp_read (opaque=, 
buf=, size=) at 
/usr/src/debug/qemu-kvm-2.8.1/monitor.c:4040
#25 0xce0eab18 in tcp_chr_read (chan=, 
cond=, opaque=0xcf90b280) at qemu_char.c:3260
#26 0x9dadf200 in g_main_context_dispatch () from 
/lib64/libglib-2.0.so.0

#27 0xce3c4a00 in glib_pollfds_poll () at util/main_loop.c:230
--Type  for more, q to quit, c to continue without paging--
#28 0xce3c4a88 in os_host_main_loop_wait (timeout=out>) at util/main_loop.c:278
#29 0xce3c4bf0 in main_loop_wait (nonblocking=) 
at util/main_loop.c:534

#30 0xce0f5d08 in main_loop () at vl.c:2120
#31 0xcdf3a770 in main (argc=, argv=out>, envp=) at vl.c:5017


3)The bt of vcpu thread

From the bt we can see,  when do qmp sush as drive_add,  qemu main 
thread locks the qemu_global_mutex  and do pre

Re: [Qemu-devel] [PATCH] test: Fix make target check-report.tap

[Philippe Mathieu-Daudé]

On 6/4/19 10:28 AM, Paolo Bonzini wrote:
> On 04/06/19 10:09, Philippe Mathieu-Daudé wrote:
>>>  check-report.tap: $(patsubst %,check-report-qtest-%.tap, $(QTEST_TARGETS)) 
>>> check-report-unit.tap
>>> -   $(call quiet-command,./scripts/tap-merge.py $^ > $@,"GEN","$@")
>>> +   $(call quiet-command, cat $^ | scripts/tap-merge.pl >$@,"GEN","$@")
>> Paolo, did you intend to submit a new tap-merge.py script in commit
>> 9df43317b82?
>>
> 
> No, it's really just y vs l.

OK!

> 
> Reviewed-by: Paolo Bonzini 
> Cc: qemu-triv...@nongnu.org

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

Re: [Qemu-devel] [PATCH v2 21/22] s390x/tcg: Allow linux-user to use vector instructions

[Laurent Vivier]

Le 03/06/2019 à 11:06, David Hildenbrand a écrit :
> Once we unlock S390_FEAT_VECTOR for TCG, we want linux-user to be
> able to make use of it.
> 
> Reviewed-by: Richard Henderson 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/cpu.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
> index b1df63d82c..6af1a1530f 100644
> --- a/target/s390x/cpu.c
> +++ b/target/s390x/cpu.c
> @@ -145,6 +145,9 @@ static void s390_cpu_full_reset(CPUState *s)
>  #if defined(CONFIG_USER_ONLY)
>  /* user mode should always be allowed to use the full FPU */
>  env->cregs[0] |= CR0_AFP;
> +if (s390_has_feat(S390_FEAT_VECTOR)) {
> +env->cregs[0] |= CR0_VECTOR;
> +}
>  #endif
>  
>  /* architectured initial value for Breaking-Event-Address register */
> 

Do we need to add some hwcaps in linux-user/elfload.c (HWCAP_S390_VXRS,
HWCAP_S390_VXRS_EXT,...)?

Thanks,
Laurent

Re: [Qemu-devel] "make run-tcg-tests-s390x-linux-user" not working for me

[Alex Bennée]

David Hildenbrand  writes:

> On 04.06.19 09:25, David Hildenbrand wrote:
>> On 04.06.19 09:17, David Hildenbrand wrote:
>>> Hi,
>>>
>>> for now I was able to run TCG tests using "make
>>> run-tcg-tests-s390x-linux-user". Lately, trying to run the tests always
>>> results in
>>>
>>> t460s: ~/git/qemu vx $ LANG=C make run-tcg-tests-s390x-linux-user
>>> make[1]: Entering directory '/home/dhildenb/git/qemu/slirp'
>>> make[1]: Nothing to be done for 'all'.
>>> make[1]: Leaving directory '/home/dhildenb/git/qemu/slirp'
>>> CHK version_gen.h
>>>   BUILD   TCG tests for s390x-linux-user
>>>   BUILD   s390x guest-tests SKIPPED
>>>   RUN TCG tests for s390x-linux-user
>>>   RUN tests for s390x SKIPPED
>>>
>>> t460s: ~/git/qemu vx $ LANG=C make check-tcg
>>> make[1]: Entering directory '/home/dhildenb/git/qemu/slirp'
>>> make[1]: Nothing to be done for 'all'.
>>> make[1]: Leaving directory '/home/dhildenb/git/qemu/slirp'
>>> CHK version_gen.h
>>>   BUILD   TCG tests for s390x-softmmu
>>>   BUILD   s390x guest-tests SKIPPED
>>>   RUN TCG tests for s390x-softmmu
>>>   RUN tests for s390x SKIPPED
>>>   BUILD   TCG tests for s390x-linux-user
>>>   BUILD   s390x guest-tests SKIPPED
>>>   RUN TCG tests for s390x-linux-user
>>>   RUN tests for s390x SKIPPED
>>>
>>> I am using "./configure --target-list=s390x-softmmu,s390x-linux-user
>>> --enable-sdl --enable-spice --enable-kvm"
>>>
>>> What am I missing? Why is the build skipped?
>>>
>>
>> BTW, docker seems to be working fine, just tried with "make
>> docker-test-build@debian-armhf-cross J=n"
>>
>
> Turns out I had to rerun ./configure (it didn't include HAVE_USER_DOCKER
> for some reason).

Yeah that was a relatively recent addition rather than dynamically
probing everytime we ran.

>
> Sorry for the noise :)


--
Alex Bennée

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

[Kevin Wolf]

Am 04.06.2019 um 10:28 hat Klaus Birkelund geschrieben:
> On Mon, Jun 03, 2019 at 09:30:53AM -0600, Heitke, Kenneth wrote:
> > 
> > 
> > On 6/3/2019 5:14 AM, Kevin Wolf wrote:
> > > Am 28.05.2019 um 08:18 hat Klaus Birkelund geschrieben:
> > > > On Mon, May 20, 2019 at 11:40:30AM -0600, Kenneth Heitke wrote:
> > > > > Signed-off-by: Kenneth Heitke 
> > > 
> > > > > diff --git a/hw/block/nvme.h b/hw/block/nvme.h
> > > > > index 56c9d4b4b1..d7277e72b7 100644
> > > > > --- a/hw/block/nvme.h
> > > > > +++ b/hw/block/nvme.h
> > > > > @@ -69,6 +69,7 @@ typedef struct NvmeCtrl {
> > > > >   uint16_tmax_prp_ents;
> > > > >   uint16_tcqe_size;
> > > > >   uint16_tsqe_size;
> > > > > +uint16_toncs;
> > > > 
> > > > Looks like this unused member snuck its way into the patch. But I see no
> > > > harm in it being there.
> > > 
> > > Good catch. I'll just remove it again from my branch.
> > > 
> > > > > +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);
> > > 
> > > Here I wonder why we use QEMU_CLOCK_REALTIME in a device emulation.
> > > Wouldn't QEMU_CLOCK_VIRTUAL make more sense?
> > > 
> > 
> > QEMU_CLOCK_VIRTUAL probably would make more sense. When I was reading
> > through the differences I wasn't really sure what to pick. iven that this is
> > the time within the device's context, the virtual time seems more correct.
> > 
>  
> I thought about this too when I reviewed, but came to the conclusion
> that REALTIME was correct. The timestamp is basically a value that the
> host stores in the controller. When the host uses Get Features to get
> the the current time it would expect it to match the progression for its
> own wall clockright? If I understand REALTIME vs VIRTUAL correctly,
> using VIRTUAL, it would go way out of sync.

Which two things would go out of sync with VIRTUAL?

Not an expert on clocks myself, but I think the main question is what
happens to the clock while the VM is stopped. REALTIME continues running
where as VIRTUAL is stopped. If we expose REALTIME measurements to the
guest, the time passed may look a lot longer than what the guest's clock
actually says. So this is the thing I am worried would go out of sync
with REALTIME.

Or did I read the code wrong and this isn't actually exposed to the
guest?

Kevin

[Qemu-devel] virtual machine cpu soft lockup when qemu attach disk

[l00284672]

Hi,  I found a problem that virtual machine cpu soft lockup when I 
attach a disk to the vm in the case that


backend storage network has a large delay or IO pressure is too large.

1) The disk xml which I attached is:

    
  
  
  
  
  
  
    

2) The bt of qemu main thread:

#0 0x9d78402c in pread64 () from /lib64/libpthread.so.0
#1 0xce3357d8 in pread64 (__offset=0, __nbytes=4096, 
__buf=0xd47a5200, __fd=202) at /usr/include/bits/unistd.h:99
#2 raw_is_io_aligned (fd=fd@entry=202, buf=buf@entry=0xd47a5200, 
len=len@entry=4096) at block/raw_posix.c:294
#3 0xce33597c in raw_probe_alignment 
(bs=bs@entry=0xd32ea920, fd=202, errp=errp@entry=0xfef7a330) at 
block/raw_posix.c:349
#4 0xce335a48 in raw_refresh_limits (bs=0xd32ea920, 
errp=0xfef7a330) at block/raw_posix.c:811
#5 0xce3404b0 in bdrv_refresh_limits (bs=0xd32ea920, 
errp=0xfef7a330, errp@entry=0xfef7a360) at block/io.c:122
#6 0xce340504 in bdrv_refresh_limits 
(bs=bs@entry=0xd09ce800, errp=errp@entry=0xfef7a3b0) at 
block/io.c:97
#7 0xce2eb9f0 in bdrv_open_common (bs=bs@entry=0xd09ce800, 
file=file@entry=0xd0e89800, options=, 
errp=errp@entry=0xfef7a450)

at block.c:1194
#8 0xce2eedec in bdrv_open_inherit (filename=, 
filename@entry=0xd25f92d0 
"/dev/mapper/36384c4f100630193359db7a8011d",
reference=reference@entry=0x0, options=, 
options@entry=0xd3d0f4b0, flags=, flags@entry=128, 
parent=parent@entry=0x0,
child_role=child_role@entry=0x0, errp=errp@entry=0xfef7a710) at 
block.c:1895
#9 0xce2ef510 in bdrv_open 
(filename=filename@entry=0xd25f92d0 
"/dev/mapper/36384c4f100630193359db7a8011d", 
reference=reference@entry=0x0,
options=options@entry=0xd3d0f4b0, flags=flags@entry=128, 
errp=errp@entry=0xfef7a710) at block.c:1979
#10 0xce331ef0 in blk_new_open 
(filename=filename@entry=0xd25f92d0 
"/dev/mapper/36384c4f100630193359db7a8011d", 
reference=reference@entry=0x0,
options=options@entry=0xd3d0f4b0, flags=128, 
errp=errp@entry=0xfef7a710) at block/block_backend.c:213
#11 0xce0da1f4 in blockdev_init (file=file@entry=0xd25f92d0 
"/dev/mapper/36384c4f100630193359db7a8011d", 
bs_opts=bs_opts@entry=0xd3d0f4b0,

errp=errp@entry=0xfef7a710) at blockdev.c:603
#12 0xce0dc478 in drive_new 
(all_opts=all_opts@entry=0xd4dc31d0, block_default_type=out>) at blockdev.c:1116

#13 0xce0e3ee0 in add_init_drive (
optstr=optstr@entry=0xd0872ec0 
"file=/dev/mapper/36384c4f100630193359db7a8011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native")

at device_hotplug.c:46
#14 0xce0e3f78 in hmp_drive_add (mon=0xfef7a810, 
qdict=0xd0c8f000) at device_hotplug.c:67
#15 0xcdf7d688 in handle_hmp_command (mon=0xfef7a810, 
cmdline=) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:3199

#16 0xcdf7d778 in qmp_human_monitor_command (
command_line=0xcfc8e3c0 "drive_add dummy 
file=/dev/mapper/36384c4f100630193359db7a8011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native", 

has_cpu_index=false, cpu_index=0, errp=errp@entry=0xfef7a968) at 
/usr/src/debug/qemu-kvm-2.8.1/monitor.c:660
#17 0xce0fdb30 in qmp_marshal_human_monitor_command 
(args=, ret=0xfef7a9e0, errp=0xfef7a9d8) at 
qmp-marshal.c:2223
#18 0xce3b6ad0 in do_qmp_dispatch (request=, 
errp=0xfef7aa20, errp@entry=0xfef7aa40) at qapi/qmp_dispatch.c:115
#19 0xce3b6d58 in qmp_dispatch (request=) at 
qapi/qmp_dispatch.c:142
#20 0xcdf79398 in handle_qmp_command (parser=, 
tokens=) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:4010
#21 0xce3bd6c0 in json_message_process_token 
(lexer=0xcf834c80, input=, type=JSON_RCURLY, x=214, 
y=274) at qobject/json_streamer.c:105
#22 0xce3f3d4c in json_lexer_feed_char 
(lexer=lexer@entry=0xcf834c80, ch=, 
flush=flush@entry=false) at qobject/json_lexer.c:319
#23 0xce3f3e6c in json_lexer_feed (lexer=0xcf834c80, 
buffer=, size=) at qobject/json_lexer.c:369
#24 0xcdf77c64 in monitor_qmp_read (opaque=, 
buf=, size=) at 
/usr/src/debug/qemu-kvm-2.8.1/monitor.c:4040
#25 0xce0eab18 in tcp_chr_read (chan=, 
cond=, opaque=0xcf90b280) at qemu_char.c:3260
#26 0x9dadf200 in g_main_context_dispatch () from 
/lib64/libglib-2.0.so.0

#27 0xce3c4a00 in glib_pollfds_poll () at util/main_loop.c:230
--Type  for more, q to quit, c to continue without paging--
#28 0xce3c4a88 in os_host_main_loop_wait (timeout=out>) at util/main_loop.c:278
#29 0xce3c4bf0 in main_loop_wait (nonblocking=) 
at util/main_loop.c:534

#30 0xce0f5d08 in main_loop () at vl.c:2120
#31 0xcdf3a770 in main (argc=, argv=out>, envp=) at vl.c:5017


3)The bt of vcpu thread

From the bt we can see,  when do qmp sush as drive_add,  qemu main 
thread locks the qemu_global_mutex  and do

Re: [Qemu-devel] [PATCH v2 21/22] s390x/tcg: Allow linux-user to use vector instructions

[David Hildenbrand]

On 04.06.19 10:50, Laurent Vivier wrote:
> Le 03/06/2019 à 11:06, David Hildenbrand a écrit :
>> Once we unlock S390_FEAT_VECTOR for TCG, we want linux-user to be
>> able to make use of it.
>>
>> Reviewed-by: Richard Henderson 
>> Signed-off-by: David Hildenbrand 
>> ---
>>  target/s390x/cpu.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
>> index b1df63d82c..6af1a1530f 100644
>> --- a/target/s390x/cpu.c
>> +++ b/target/s390x/cpu.c
>> @@ -145,6 +145,9 @@ static void s390_cpu_full_reset(CPUState *s)
>>  #if defined(CONFIG_USER_ONLY)
>>  /* user mode should always be allowed to use the full FPU */
>>  env->cregs[0] |= CR0_AFP;
>> +if (s390_has_feat(S390_FEAT_VECTOR)) {
>> +env->cregs[0] |= CR0_VECTOR;
>> +}
>>  #endif
>>  
>>  /* architectured initial value for Breaking-Event-Address register */
>>
> 
> Do we need to add some hwcaps in linux-user/elfload.c (HWCAP_S390_VXRS,
> HWCAP_S390_VXRS_EXT,...)?

Good point, I will look into this. Thanks!

> 
> Thanks,
> Laurent
> 


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v9 4/6] target/ppc: Build rtas error log upon an MCE

[Greg Kurz]

On Tue, 4 Jun 2019 11:59:13 +0530
Aravinda Prasad  wrote:

> On Monday 03 June 2019 07:30 PM, Greg Kurz wrote:
> > On Wed, 29 May 2019 11:10:40 +0530
> > Aravinda Prasad  wrote:
> >   
> >> Upon a machine check exception (MCE) in a guest address space,
> >> KVM causes a guest exit to enable QEMU to build and pass the
> >> error to the guest in the PAPR defined rtas error log format.
> >>
> >> This patch builds the rtas error log, copies it to the rtas_addr
> >> and then invokes the guest registered machine check handler. The
> >> handler in the guest takes suitable action(s) depending on the type
> >> and criticality of the error. For example, if an error is
> >> unrecoverable memory corruption in an application inside the
> >> guest, then the guest kernel sends a SIGBUS to the application.
> >> For recoverable errors, the guest performs recovery actions and
> >> logs the error.
> >>
> >> Signed-off-by: Aravinda Prasad 
> >> ---
> >>  hw/ppc/spapr.c |5 +
> >>  hw/ppc/spapr_events.c  |  236 
> >> 
> >>  include/hw/ppc/spapr.h |4 +
> >>  3 files changed, 245 insertions(+)
> >>
> >> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> >> index 6b6c962..c97f6a6 100644
> >> --- a/hw/ppc/spapr.c
> >> +++ b/hw/ppc/spapr.c
> >> @@ -2910,6 +2910,11 @@ static void spapr_machine_init(MachineState 
> >> *machine)
> >>  error_report("Could not get size of LPAR rtas '%s'", filename);
> >>  exit(1);
> >>  }
> >> +
> >> +/* Resize blob to accommodate error log. */
> >> +g_assert(spapr->rtas_size < RTAS_ERROR_LOG_OFFSET);  
> > 
> > I don't see the point of this assertion... especially with the assignment
> > below.  
> 
> It is required because we want to ensure that the rtas image size is
> less than RTAS_ERROR_LOG_OFFSET, or else we will overwrite the rtas
> image with rtas error when we hit machine check exception. But I think a
> comment in the code will help. Will add it.
> 

I'd rather exit QEMU properly instead of aborting then. Also this is only
needed if the guest has a chance to use FWNMI, ie. the spapr cap is set.

> 
> >   
> >> +spapr->rtas_size = RTAS_ERROR_LOG_MAX;  
> > 
> > As requested by David, this should only be done when the spapr cap is set,
> > so that 4.0 machine types and older continue to use the current size.  
> 
> Due to other issue of re-allocating the blob and as this is not that
> much space, we agreed to keep the size to RTAS_ERROR_LOG_MAX always.
> 
> Link to the discussion on this:
> http://lists.nongnu.org/archive/html/qemu-ppc/2019-05/msg00275.html
> 

Indeed, and in the next mail in that thread, David writes:

> No, that's not right.  It's impractical to change the allocation
> depending on whether fwnmi is currently active.  But you *can* (and
> should) base the allocation on whether fwnmi is *possible* - that is,
> the value of the spapr cap.

ie, allocate RTAS_ERROR_LOG_MAX when the spapr cap is set, allocate
the file size otherwise.

> >   
> >> +
> >>  spapr->rtas_blob = g_malloc(spapr->rtas_size);
> >>  if (load_image_size(filename, spapr->rtas_blob, spapr->rtas_size) < 
> >> 0) {
> >>  error_report("Could not load LPAR rtas '%s'", filename);
> >> diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
> >> index a18446b..573c0b7 100644
> >> --- a/hw/ppc/spapr_events.c
> >> +++ b/hw/ppc/spapr_events.c
> >> @@ -212,6 +212,106 @@ struct hp_extended_log {
> >>  struct rtas_event_log_v6_hp hp;
> >>  } QEMU_PACKED;
> >>  
> >> +struct rtas_event_log_v6_mc {
> >> +#define RTAS_LOG_V6_SECTION_ID_MC   0x4D43 /* MC */
> >> +struct rtas_event_log_v6_section_header hdr;
> >> +uint32_t fru_id;
> >> +uint32_t proc_id;
> >> +uint8_t error_type;
> >> +#define RTAS_LOG_V6_MC_TYPE_UE   0
> >> +#define RTAS_LOG_V6_MC_TYPE_SLB  1
> >> +#define RTAS_LOG_V6_MC_TYPE_ERAT 2
> >> +#define RTAS_LOG_V6_MC_TYPE_TLB  4
> >> +#define RTAS_LOG_V6_MC_TYPE_D_CACHE  5
> >> +#define RTAS_LOG_V6_MC_TYPE_I_CACHE  7
> >> +uint8_t sub_err_type;
> >> +#define RTAS_LOG_V6_MC_UE_INDETERMINATE  0
> >> +#define RTAS_LOG_V6_MC_UE_IFETCH 1
> >> +#define RTAS_LOG_V6_MC_UE_PAGE_TABLE_WALK_IFETCH 2
> >> +#define RTAS_LOG_V6_MC_UE_LOAD_STORE 3
> >> +#define RTAS_LOG_V6_MC_UE_PAGE_TABLE_WALK_LOAD_STORE 4
> >> +#define RTAS_LOG_V6_MC_SLB_PARITY0
> >> +#define RTAS_LOG_V6_MC_SLB_MULTIHIT  1
> >> +#define RTAS_LOG_V6_MC_SLB_INDETERMINATE 2
> >> +#define RTAS_LOG_V6_MC_ERAT_PARITY   1
> >> +#define RTAS_LOG_V6_MC_ERAT_MULTIHIT 2
> >> +#define RTAS_LOG_V6_MC_ERAT_INDETERMINATE3
> >> +#define RTAS_LOG_V6_MC_TLB_PARITY1
> >> +#define RTAS_LOG_V6_

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

[Klaus Birkelund]

On Tue, Jun 04, 2019 at 10:46:45AM +0200, Kevin Wolf wrote:
> Am 04.06.2019 um 10:28 hat Klaus Birkelund geschrieben:
> > On Mon, Jun 03, 2019 at 09:30:53AM -0600, Heitke, Kenneth wrote:
> > > 
> > > 
> > > On 6/3/2019 5:14 AM, Kevin Wolf wrote:
> > > > Am 28.05.2019 um 08:18 hat Klaus Birkelund geschrieben:
> > > > > On Mon, May 20, 2019 at 11:40:30AM -0600, Kenneth Heitke wrote:
> > > > > > Signed-off-by: Kenneth Heitke 
> > > > 
> > > > > > diff --git a/hw/block/nvme.h b/hw/block/nvme.h
> > > > > > index 56c9d4b4b1..d7277e72b7 100644
> > > > > > --- a/hw/block/nvme.h
> > > > > > +++ b/hw/block/nvme.h
> > > > > > @@ -69,6 +69,7 @@ typedef struct NvmeCtrl {
> > > > > >   uint16_tmax_prp_ents;
> > > > > >   uint16_tcqe_size;
> > > > > >   uint16_tsqe_size;
> > > > > > +uint16_toncs;
> > > > > 
> > > > > Looks like this unused member snuck its way into the patch. But I see 
> > > > > no
> > > > > harm in it being there.
> > > > 
> > > > Good catch. I'll just remove it again from my branch.
> > > > 
> > > > > > +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);
> > > > 
> > > > Here I wonder why we use QEMU_CLOCK_REALTIME in a device emulation.
> > > > Wouldn't QEMU_CLOCK_VIRTUAL make more sense?
> > > > 
> > > 
> > > QEMU_CLOCK_VIRTUAL probably would make more sense. When I was reading
> > > through the differences I wasn't really sure what to pick. iven that this 
> > > is
> > > the time within the device's context, the virtual time seems more correct.
> > > 
> >  
> > I thought about this too when I reviewed, but came to the conclusion
> > that REALTIME was correct. The timestamp is basically a value that the
> > host stores in the controller. When the host uses Get Features to get
> > the the current time it would expect it to match the progression for its
> > own wall clockright? If I understand REALTIME vs VIRTUAL correctly,
> > using VIRTUAL, it would go way out of sync.
> 
> Which two things would go out of sync with VIRTUAL?
> 
> Not an expert on clocks myself, but I think the main question is what
> happens to the clock while the VM is stopped. REALTIME continues running
> where as VIRTUAL is stopped. If we expose REALTIME measurements to the
> guest, the time passed may look a lot longer than what the guest's clock
> actually says. So this is the thing I am worried would go out of sync
> with REALTIME.
> 

OK, fair point.

Thinking about this some more, I agree that VIRTUAL is more correct. An
application should never track elapsed time using real wall clock time,
but some monotonic clock that is oblivious to say NTP adjustments.

Klaus

[Qemu-devel] [PATCH 0/2] ui/cocoa: Fix input device issues on Mojave

[Chen Zhang via Qemu-devel]

The following patches fixed issues of absolute and relative input devices 
on macOS Mojave.

Chen Zhang (2):
  ui/cocoa: Fix absolute input device grabbing issue on Mojave
  ui/cocoa: Fix mouse grabbing in fullscreen mode for relative input
device

 ui/cocoa.m | 50 +++---
 1 file changed, 47 insertions(+), 3 deletions(-)

-- 
2.21.0

[Qemu-devel] [PATCH 1/2] ui/cocoa: Fix absolute input device grabbing issue on Mojave

[Chen Zhang via Qemu-devel]

On Mojave, absolute input device, i.e. tablet, had trouble re-grabbing
the cursor in re-entry into the virtual screen area. In some cases,
the `window` property of NSEvent object was nil after cursor exiting from
window, hinting that the `-locationInWindow` method would return value in 
screen coordinates. The current implementation used raw locations from 
NSEvent without considering whether the value was for the window coordinates
or the macOS screen coordinates, nor the zooming factor for Zoom-to-Fit in
fullscreen mode.

In fullscreen mode, the fullscreen cocoa window might not be the key
window, therefore the location of event in virtual coordinates should
suffice.

This patches fixed boundary check methods for cursor in normal
and fullscreen with/without Zoom-to-Fit in Mojave.

Note: CGRect, -convertRectToScreen: and -convertRectFromScreen: were
used in coordinates conversion for compatibility reason.

Signed-off-by: Chen Zhang 
---
 ui/cocoa.m | 43 +--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 420b2411c1..474d44cb9f 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -405,6 +405,41 @@ QemuCocoaView *cocoaView;
 return (p.x > -1 && p.x < screen.width && p.y > -1 && p.y < screen.height);
 }
 
+/* Get location of event and convert to virtual screen coordinate */
+- (CGPoint) screenLocationOfEvent:(NSEvent *)ev
+{
+NSWindow *eventWindow = [ev window];
+// XXX: Use CGRect and -convertRectFromScreen: to support macOS 10.10
+CGRect r = CGRectZero;
+r.origin = [ev locationInWindow];
+if (!eventWindow) {
+if (!isFullscreen) {
+return [[self window] convertRectFromScreen:r].origin;
+} else {
+CGPoint locationInSelfWindow = [[self window] 
convertRectFromScreen:r].origin;
+CGPoint loc = [self convertPoint:locationInSelfWindow 
fromView:nil];
+if (stretch_video) {
+loc.x /= cdx;
+loc.y /= cdy;
+}
+return loc;
+}
+} else if ([[self window] isEqual:eventWindow]) {
+if (!isFullscreen) {
+return r.origin;
+} else {
+CGPoint loc = [self convertPoint:r.origin fromView:nil];
+if (stretch_video) {
+loc.x /= cdx;
+loc.y /= cdy;
+}
+return loc;
+}
+} else {
+return [[self window] convertRectFromScreen:[eventWindow 
convertRectToScreen:r]].origin;
+}
+}
+
 - (void) hideCursor
 {
 if (!cursor_hide) {
@@ -704,7 +739,8 @@ QemuCocoaView *cocoaView;
 int keycode = 0;
 bool mouse_event = false;
 static bool switched_to_fullscreen = false;
-NSPoint p = [event locationInWindow];
+// Location of event in virtual screen coordinates
+NSPoint p = [self screenLocationOfEvent:event];
 
 switch ([event type]) {
 case NSEventTypeFlagsChanged:
@@ -815,7 +851,10 @@ QemuCocoaView *cocoaView;
 break;
 case NSEventTypeMouseMoved:
 if (isAbsoluteEnabled) {
-if (![self screenContainsPoint:p] || ![[self window] 
isKeyWindow]) {
+// Cursor re-entered into a window might generate events bound 
to screen coordinates
+// and `nil` window property, and in full screen mode, current 
window might not be
+// key window, where event location alone should suffice.
+if (![self screenContainsPoint:p] || !([[self window] 
isKeyWindow] || isFullscreen)) {
 if (isMouseGrabbed) {
 [self ungrabMouse];
 }
-- 
2.21.0

[Qemu-devel] [PATCH 2/2] ui/cocoa: Fix mouse grabbing in fullscreen mode for relative input device

[Chen Zhang via Qemu-devel]

In fullscreen mode, the window property of cocoaView may not be the key
window, and the current implementation would not re-grab cursor by left click
in fullscreen mode after ungrabbed in fullscreen mode with hot-key ctrl-opt-g.

This patch used value of isFullscreen as a short-cirtuit condition for
relative input device grabbing.

Signed-off-by: Chen Zhang 
---
 ui/cocoa.m | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 474d44cb9f..aa7cf07368 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -901,7 +901,12 @@ QemuCocoaView *cocoaView;
 case NSEventTypeLeftMouseUp:
 mouse_event = true;
 if (!isMouseGrabbed && [self screenContainsPoint:p]) {
-if([[self window] isKeyWindow]) {
+/*
+ * In fullscreen mode, the window of cocoaView may not be the
+ * key window, therefore the position relative to the virtual
+ * screen alone will be sufficient.
+ */
+if(isFullscreen || [[self window] isKeyWindow]) {
 [self grabMouse];
 }
 }
-- 
2.21.0

[Qemu-devel] [PATCH v1] linux-user: elf: ELF_HWCAP for s390x

[David Hildenbrand]

Let's add all HWCAPs that we can support under TCG right now, when the
respective CPU facilities are enabled.

Cc: Riku Voipio 
Cc: Laurent Vivier 
Cc: Cornelia Huck 
Cc: Laurent Vivier 
Cc: Richard Henderson 
Signed-off-by: David Hildenbrand 
---

This patch is based on "[PATCH v2 00/22] s390x/tcg: Vector Instruction
Support Part 4". I guess it is best if I just include it in my next
pull request.

---
 include/elf.h|  1 +
 linux-user/elfload.c | 39 +++
 2 files changed, 40 insertions(+)

diff --git a/include/elf.h b/include/elf.h
index ea7708a4ea..3501e0c8d0 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -598,6 +598,7 @@ typedef struct {
 #define HWCAP_S390_ETF3EH   256
 #define HWCAP_S390_HIGH_GPRS512
 #define HWCAP_S390_TE   1024
+#define HWCAP_S390_VXRS 2048
 
 /* M68K specific definitions. */
 /* We use the top 24 bits to encode information about the
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index a57b7049dd..59b813066c 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1308,6 +1308,45 @@ static inline void init_thread(struct target_pt_regs 
*regs,
 #define ELF_DATA   ELFDATA2MSB
 #define ELF_ARCH   EM_S390
 
+#include "elf.h"
+
+#define ELF_HWCAP get_elf_hwcap()
+
+static uint32_t get_elf_hwcap(void)
+{
+uint32_t hwcap = 0;
+
+if (s390_has_feat(S390_FEAT_ESAN3)) {
+hwcap |= HWCAP_S390_ESAN3;
+}
+if (s390_has_feat(S390_FEAT_ZARCH)) {
+hwcap |= HWCAP_S390_ZARCH;
+}
+if (s390_has_feat(S390_FEAT_STFLE)) {
+hwcap |= HWCAP_S390_STFLE;
+}
+if (s390_has_feat(S390_FEAT_MSA)) {
+hwcap |= HWCAP_S390_MSA;
+}
+if (s390_has_feat(S390_FEAT_LONG_DISPLACEMENT)) {
+hwcap |= HWCAP_S390_LDISP;
+}
+if (s390_has_feat(S390_FEAT_EXTENDED_IMMEDIATE)) {
+hwcap |= HWCAP_S390_EIMM;
+}
+if (s390_has_feat(S390_FEAT_EXTENDED_TRANSLATION_3) &&
+s390_has_feat(S390_FEAT_ETF3_ENH)) {
+hwcap |= HWCAP_S390_ETF3EH;
+}
+/* 31-bit processes can use 64-bit registers */
+hwcap |= HWCAP_S390_HIGH_GPRS;
+if (s390_has_feat(S390_FEAT_VECTOR)) {
+hwcap |= HWCAP_S390_VXRS;
+}
+
+return hwcap;
+}
+
 static inline void init_thread(struct target_pt_regs *regs, struct image_info 
*infop)
 {
 regs->psw.addr = infop->entry;
-- 
2.21.0

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

[Corentin Labbe]

On Wed, May 22, 2019 at 02:23:23AM +0300, Aaro Koskinen wrote:
> Hi,
> 
> On Mon, May 20, 2019 at 09:05:33PM +0200, Corentin Labbe wrote:
> > Hello
> > 
> > I am working on adding a maximum set of qemu machine on kernelCI.
> 
> That's cool.
> 
> > For OMAP, five machine exists and I fail to boot any of them.
> 
> Which machines?
> 
> > The maximum I can get with omap1_defconfig is
> > qemu-system-arm -kernel zImage -nographic -machine cheetah -append 
> > 'root=/dev/ram0 console=ttyO0'
> > Uncompressing Linux... done, booting the kernel.
> > then nothing more.
> 
> It's known that omap1_defconfig doesn't work well for QEMU or
> "multi-board" usage. Perhaps the kernel size is now just too big?
> I'm using a custom config for every OMAP1 board anyway...
> 
> > Does someone have a working config+version to share ?
> 
> I have used the below config for OMAP1 SX1 board (the only one I got
> working with QEMU). Unfortunately the functionality is quite limited,
> but it still allows to run e.g. GCC bootstrap & testsuite, that is rare
> nowadays for armv4t.
> 
> I'm using the following command line with qemu-system-arm 3.1.0:
> 
> -M sx1 \
> -kernel "sx1-zImage" \
> -nographic \
> -drive file="sx1-mmc",if=sd,format=raw \
> -no-reboot
> 
> This should work with v5.1 kernel.
> 
> I'm also interested to run other OMAP kernels under QEMU, e.g. cheetah
> (the real device, Palm TE works OK with the current mainline), and it
> would be interesting to know why QEMU/kernel has regressed...
> 

Thanks, with your config as starting point, I was able to boot both sx1 and 
cheetah

So I now use the omap1_defconfig and the only trick is to disable 
CONFIG_CPU_DCACHE_WRITETHROUGH.
I need also to disable CONFIG_FB for cheetah to works.

Regards

Re: [Qemu-devel] [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load

[Alex Bennée]

Andrew Randrianasulu  writes:

> В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а):
>> When running on 32 bit TCG backends a wide unaligned load ends up
>> truncating data before returning to the guest. We specifically have
>> the return type as uint64_t to avoid any premature truncation so we
>> should use the same for the interim types.
>>
>> Hopefully fixes #1830872
>>
>> Signed-off-by: Alex Bennée 
>> ---
>>  accel/tcg/cputlb.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
>> index cdcc3771020..b796ab1cbea 100644
>> --- a/accel/tcg/cputlb.c
>> +++ b/accel/tcg/cputlb.c
>> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, 
>> TCGMemOpIdx oi,
>>  && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
>>  >= TARGET_PAGE_SIZE)) {
>>  target_ulong addr1, addr2;
>> -tcg_target_ulong r1, r2;
>> +uint64_t r1, r2;
>>  unsigned shift;
>>  do_unaligned_access:
>>  addr1 = addr & ~(size - 1);
>
> Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64  so, my
> bug is separate from #1830872 ?

I think you've hit two - one of which we have just fixed. With my
expanded memory test on i386 I'm seeing a hang but it's ok @
pull-demacro-softmmu-100519-1. Unfortunately bisecting through the slirp
move and other i386 Werror stuff is proving painful.

>
> I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 
> cross-compiler ..
> probably x86-64 testing on i686 requires either docker (I don't have this
> ) or 'real' cross-compiler (build with glibc support).


--
Alex Bennée

[Qemu-devel] [RFC PATCH 1/3] vfio: Add a funtion to return a specific irq capabilities

[Tina Zhang]

vfio_get_dev_irq_info is introduced to return a specific irq
capabilities.

Signed-off-by: Tina Zhang 
---
 hw/vfio/common.c  | 78 +++
 include/hw/vfio/vfio-common.h |  3 ++
 2 files changed, 81 insertions(+)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 4374cc6176..928ea54411 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -748,6 +748,25 @@ vfio_get_region_info_cap(struct vfio_region_info *info, 
uint16_t id)
 return NULL;
 }
 
+static struct vfio_info_cap_header *
+vfio_get_irq_info_cap(struct vfio_irq_info *info, uint16_t id)
+{
+struct vfio_info_cap_header *hdr;
+void *ptr = info;
+
+if (!(info->flags & VFIO_IRQ_INFO_FLAG_CAPS)) {
+return NULL;
+}
+
+for (hdr = ptr + info->cap_offset; hdr != ptr; hdr = ptr + hdr->next) {
+if (hdr->id == id) {
+return hdr;
+}
+}
+
+return NULL;
+}
+
 static int vfio_setup_region_sparse_mmaps(VFIORegion *region,
   struct vfio_region_info *info)
 {
@@ -1539,6 +1558,33 @@ retry:
 return 0;
 }
 
+static int vfio_get_irq_info(VFIODevice *vbasedev, int index,
+ struct vfio_irq_info **info)
+{
+size_t argsz = sizeof(struct vfio_irq_info);
+
+*info = g_malloc0(argsz);
+
+(*info)->index = index;
+retry:
+(*info)->argsz = argsz;
+
+if (ioctl(vbasedev->fd, VFIO_DEVICE_GET_IRQ_INFO, *info)) {
+g_free(*info);
+*info = NULL;
+return -errno;
+}
+
+if ((*info)->argsz > argsz) {
+argsz = (*info)->argsz;
+*info = g_realloc(*info, argsz);
+
+goto retry;
+}
+
+return 0;
+}
+
 int vfio_get_dev_region_info(VFIODevice *vbasedev, uint32_t type,
  uint32_t subtype, struct vfio_region_info **info)
 {
@@ -1574,6 +1620,38 @@ int vfio_get_dev_region_info(VFIODevice *vbasedev, 
uint32_t type,
 return -ENODEV;
 }
 
+int vfio_get_dev_irq_info(VFIODevice *vbasedev, uint32_t type,
+ uint32_t subtype, struct vfio_irq_info **info)
+{
+int i;
+
+for (i = 0; i < vbasedev->num_irqs; i++) {
+struct vfio_info_cap_header *hdr;
+struct vfio_irq_info_cap_type *cap_type;
+
+if (vfio_get_irq_info(vbasedev, i, info)) {
+continue;
+}
+
+hdr = vfio_get_irq_info_cap(*info, VFIO_IRQ_INFO_CAP_TYPE);
+if (!hdr) {
+g_free(*info);
+continue;
+}
+
+cap_type = container_of(hdr, struct vfio_irq_info_cap_type, header);
+
+if (cap_type->type == type && cap_type->subtype == subtype) {
+return 0;
+}
+
+g_free(*info);
+}
+
+*info = NULL;
+return -ENODEV;
+}
+
 bool vfio_has_region_cap(VFIODevice *vbasedev, int region, uint16_t cap_type)
 {
 struct vfio_region_info *info = NULL;
diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index 1155b79678..5cab6a1b81 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -195,6 +195,9 @@ int vfio_get_dev_region_info(VFIODevice *vbasedev, uint32_t 
type,
 bool vfio_has_region_cap(VFIODevice *vbasedev, int region, uint16_t cap_type);
 struct vfio_info_cap_header *
 vfio_get_region_info_cap(struct vfio_region_info *info, uint16_t id);
+
+int vfio_get_dev_irq_info(VFIODevice *vbasedev, uint32_t type,
+  uint32_t subtype, struct vfio_irq_info **info);
 #endif
 extern const MemoryListener vfio_prereg_listener;
 
-- 
2.17.1

[Qemu-devel] [RFC PATCH 2/3] ui/console: Introduce two new APIs

[Tina Zhang]

graphic_hw_refresh is used by display to invoke console refresh.
dpy_update_interval is used by display to update gui timer interval.

Signed-off-by: Tina Zhang 
---
 include/ui/console.h |  2 ++
 ui/console.c | 35 +++
 2 files changed, 37 insertions(+)

diff --git a/include/ui/console.h b/include/ui/console.h
index fef900db76..3b46264efb 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -275,6 +275,7 @@ void register_displaychangelistener(DisplayChangeListener 
*dcl);
 void update_displaychangelistener(DisplayChangeListener *dcl,
   uint64_t interval);
 void unregister_displaychangelistener(DisplayChangeListener *dcl);
+void dpy_update_interval(QemuConsole *con, uint64_t interval);
 
 bool dpy_ui_info_supported(QemuConsole *con);
 int dpy_set_ui_info(QemuConsole *con, QemuUIInfo *info);
@@ -379,6 +380,7 @@ void graphic_console_set_hwops(QemuConsole *con,
 void graphic_console_close(QemuConsole *con);
 
 void graphic_hw_update(QemuConsole *con);
+void graphic_hw_refresh(QemuConsole *con);
 void graphic_hw_invalidate(QemuConsole *con);
 void graphic_hw_text_update(QemuConsole *con, console_ch_t *chardata);
 void graphic_hw_gl_block(QemuConsole *con, bool block);
diff --git a/ui/console.c b/ui/console.c
index 6d2282d3e9..3a02cea37d 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -268,6 +268,24 @@ void graphic_hw_update(QemuConsole *con)
 }
 }
 
+void graphic_hw_refresh(QemuConsole *con)
+{
+DisplayState *ds;
+DisplayChangeListener *dcl;
+
+if (!con) {
+con = active_console;
+}
+
+ds = con->ds;
+
+QLIST_FOREACH(dcl, &ds->listeners, next) {
+if (dcl->ops->dpy_refresh) {
+dcl->ops->dpy_refresh(dcl);
+}
+}
+}
+
 void graphic_hw_gl_block(QemuConsole *con, bool block)
 {
 assert(con != NULL);
@@ -1480,6 +1498,23 @@ void update_displaychangelistener(DisplayChangeListener 
*dcl,
 }
 }
 
+void dpy_update_interval(QemuConsole *con, uint64_t interval)
+{
+DisplayChangeListener *dcl;
+DisplayState *ds;
+
+if (!con) {
+return;
+}
+
+ds = con->ds;
+
+QLIST_FOREACH(dcl, &ds->listeners, next) {
+update_displaychangelistener(dcl, interval);
+}
+}
+
+
 void unregister_displaychangelistener(DisplayChangeListener *dcl)
 {
 DisplayState *ds = dcl->ds;
-- 
2.17.1

[Qemu-devel] [RFC PATCH 0/3] hw/display: Refresh UI depending on vGPU page flip events

[Tina Zhang]

This series shows the idea to refresh UI console depending on vGPU
page flip events.

Tina Zhang (3):
  vfio: Add a funtion to return a specific irq capabilities
  ui/console: Introduce two new APIs
  vfio/display: Refresh display depending on vGPU page flip events

 hw/vfio/common.c  |  78 +++
 hw/vfio/display.c | 249 +-
 include/hw/vfio/vfio-common.h |  11 ++
 include/ui/console.h  |   2 +
 ui/console.c  |  35 +
 5 files changed, 343 insertions(+), 32 deletions(-)

-- 
2.17.1

[Qemu-devel] [RFC PATCH 3/3] vfio/display: Refresh display depending on vGPU page flip events

[Tina Zhang]

Use vGPU plane page flip events to refresh display.

Signed-off-by: Tina Zhang 
---
 hw/vfio/display.c | 249 +-
 include/hw/vfio/vfio-common.h |   8 ++
 2 files changed, 225 insertions(+), 32 deletions(-)

diff --git a/hw/vfio/display.c b/hw/vfio/display.c
index 2c2d3e5b71..6ef383b5e8 100644
--- a/hw/vfio/display.c
+++ b/hw/vfio/display.c
@@ -288,44 +288,54 @@ static void vfio_display_dmabuf_update(void *opaque)
 VFIODMABuf *primary, *cursor;
 bool free_bufs = false, new_cursor = false;;
 
-primary = vfio_display_get_dmabuf(vdev, DRM_PLANE_TYPE_PRIMARY);
-if (primary == NULL) {
-if (dpy->ramfb) {
-ramfb_display_update(dpy->con, dpy->ramfb);
-}
-return;
+if (dpy->event_flags & VFIO_IRQ_EVENT_ENABLE) {
+dpy_update_interval(dpy->con, GUI_REFRESH_INTERVAL_IDLE);
 }
 
-if (dpy->dmabuf.primary != primary) {
-dpy->dmabuf.primary = primary;
-qemu_console_resize(dpy->con,
-primary->buf.width, primary->buf.height);
-dpy_gl_scanout_dmabuf(dpy->con, &primary->buf);
-free_bufs = true;
-}
+if (!dpy->event_flags ||
+(dpy->event_flags & VFIO_IRQ_EVENT_PRIMRAY_PLANE_FLIP)) {
+primary = vfio_display_get_dmabuf(vdev, DRM_PLANE_TYPE_PRIMARY);
+if (primary == NULL) {
+if (dpy->ramfb) {
+ramfb_display_update(dpy->con, dpy->ramfb);
+}
+return;
+}
 
-cursor = vfio_display_get_dmabuf(vdev, DRM_PLANE_TYPE_CURSOR);
-if (dpy->dmabuf.cursor != cursor) {
-dpy->dmabuf.cursor = cursor;
-new_cursor = true;
-free_bufs = true;
+if (dpy->dmabuf.primary != primary) {
+dpy->dmabuf.primary = primary;
+qemu_console_resize(dpy->con,
+primary->buf.width, primary->buf.height);
+dpy_gl_scanout_dmabuf(dpy->con, &primary->buf);
+free_bufs = true;
+}
 }
 
-if (cursor && (new_cursor || cursor->hot_updates)) {
-bool have_hot = (cursor->hot_x != 0x &&
- cursor->hot_y != 0x);
-dpy_gl_cursor_dmabuf(dpy->con, &cursor->buf, have_hot,
- cursor->hot_x, cursor->hot_y);
-cursor->hot_updates = 0;
-} else if (!cursor && new_cursor) {
-dpy_gl_cursor_dmabuf(dpy->con, NULL, false, 0, 0);
-}
+if (!dpy->event_flags ||
+(dpy->event_flags & VFIO_IRQ_EVENT_CURSOR_PLANE_FLIP)) {
+cursor = vfio_display_get_dmabuf(vdev, DRM_PLANE_TYPE_CURSOR);
+if (dpy->dmabuf.cursor != cursor) {
+dpy->dmabuf.cursor = cursor;
+new_cursor = true;
+free_bufs = true;
+}
+
+if (cursor && (new_cursor || cursor->hot_updates)) {
+bool have_hot = (cursor->hot_x != 0x &&
+ cursor->hot_y != 0x);
+dpy_gl_cursor_dmabuf(dpy->con, &cursor->buf, have_hot,
+ cursor->hot_x, cursor->hot_y);
+cursor->hot_updates = 0;
+} else if (!cursor && new_cursor) {
+dpy_gl_cursor_dmabuf(dpy->con, NULL, false, 0, 0);
+}
 
-if (cursor && cursor->pos_updates) {
-dpy_gl_cursor_position(dpy->con,
-   cursor->pos_x,
-   cursor->pos_y);
-cursor->pos_updates = 0;
+if (cursor && cursor->pos_updates) {
+dpy_gl_cursor_position(dpy->con,
+   cursor->pos_x,
+   cursor->pos_y);
+cursor->pos_updates = 0;
+}
 }
 
 dpy_gl_update(dpy->con, 0, 0, primary->buf.width, primary->buf.height);
@@ -340,6 +350,7 @@ static const GraphicHwOps vfio_display_dmabuf_ops = {
 .ui_info= vfio_display_edid_ui_info,
 };
 
+static int vfio_register_display_notifier(VFIOPCIDevice *vdev);
 static int vfio_display_dmabuf_init(VFIOPCIDevice *vdev, Error **errp)
 {
 if (!display_opengl) {
@@ -355,6 +366,8 @@ static int vfio_display_dmabuf_init(VFIOPCIDevice *vdev, 
Error **errp)
 vdev->dpy->ramfb = ramfb_setup(DEVICE(vdev), errp);
 }
 vfio_display_edid_init(vdev);
+vfio_register_display_notifier(vdev);
+
 return 0;
 }
 
@@ -495,6 +508,177 @@ static void vfio_display_region_exit(VFIODisplay *dpy)
 
 /* -- */
 
+static void primary_plane_update(void *opaque)
+{
+VFIOPCIDevice *vdev = opaque;
+VFIODisplay *dpy = vdev->dpy;
+
+if (!event_notifier_test_and_clear(&dpy->pri_event_notifier)) {
+return;
+}
+
+dpy->event_flags |= VFIO_IRQ_EVENT_PRIMRAY_PLANE_FLIP;
+graphic_hw_refresh(dpy->con);
+dpy->event_flags &= ~VFIO_IRQ_EVENT_PRIMRAY_PLANE_FLIP;
+}
+
+static void cursor_plane_update(void *opaque)
+{
+VFIOPCIDevice *vdev = opaqu

Re: [Qemu-devel] [Qemu-ppc] [PATCH v9 4/6] target/ppc: Build rtas error log upon an MCE

[Aravinda Prasad]

On Tuesday 04 June 2019 02:31 PM, Greg Kurz wrote:
> On Tue, 4 Jun 2019 11:59:13 +0530
> Aravinda Prasad  wrote:
> 
>> On Monday 03 June 2019 07:30 PM, Greg Kurz wrote:
>>> On Wed, 29 May 2019 11:10:40 +0530
>>> Aravinda Prasad  wrote:
>>>   
 Upon a machine check exception (MCE) in a guest address space,
 KVM causes a guest exit to enable QEMU to build and pass the
 error to the guest in the PAPR defined rtas error log format.

 This patch builds the rtas error log, copies it to the rtas_addr
 and then invokes the guest registered machine check handler. The
 handler in the guest takes suitable action(s) depending on the type
 and criticality of the error. For example, if an error is
 unrecoverable memory corruption in an application inside the
 guest, then the guest kernel sends a SIGBUS to the application.
 For recoverable errors, the guest performs recovery actions and
 logs the error.

 Signed-off-by: Aravinda Prasad 
 ---
  hw/ppc/spapr.c |5 +
  hw/ppc/spapr_events.c  |  236 
 
  include/hw/ppc/spapr.h |4 +
  3 files changed, 245 insertions(+)

 diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
 index 6b6c962..c97f6a6 100644
 --- a/hw/ppc/spapr.c
 +++ b/hw/ppc/spapr.c
 @@ -2910,6 +2910,11 @@ static void spapr_machine_init(MachineState 
 *machine)
  error_report("Could not get size of LPAR rtas '%s'", filename);
  exit(1);
  }
 +
 +/* Resize blob to accommodate error log. */
 +g_assert(spapr->rtas_size < RTAS_ERROR_LOG_OFFSET);  
>>>
>>> I don't see the point of this assertion... especially with the assignment
>>> below.  
>>
>> It is required because we want to ensure that the rtas image size is
>> less than RTAS_ERROR_LOG_OFFSET, or else we will overwrite the rtas
>> image with rtas error when we hit machine check exception. But I think a
>> comment in the code will help. Will add it.
>>
> 
> I'd rather exit QEMU properly instead of aborting then. Also this is only
> needed if the guest has a chance to use FWNMI, ie. the spapr cap is set.

ok..

> 
>>
>>>   
 +spapr->rtas_size = RTAS_ERROR_LOG_MAX;  
>>>
>>> As requested by David, this should only be done when the spapr cap is set,
>>> so that 4.0 machine types and older continue to use the current size.  
>>
>> Due to other issue of re-allocating the blob and as this is not that
>> much space, we agreed to keep the size to RTAS_ERROR_LOG_MAX always.
>>
>> Link to the discussion on this:
>> http://lists.nongnu.org/archive/html/qemu-ppc/2019-05/msg00275.html
>>
> 
> Indeed, and in the next mail in that thread, David writes:
> 
>> No, that's not right.  It's impractical to change the allocation
>> depending on whether fwnmi is currently active.  But you *can* (and
>> should) base the allocation on whether fwnmi is *possible* - that is,
>> the value of the spapr cap.
> 
> ie, allocate RTAS_ERROR_LOG_MAX when the spapr cap is set, allocate
> the file size otherwise.

Ah.. somehow this slipped off my mind...

Regards,
Aravinda

> 
>>>   
 +
  spapr->rtas_blob = g_malloc(spapr->rtas_size);
  if (load_image_size(filename, spapr->rtas_blob, spapr->rtas_size) < 
 0) {
  error_report("Could not load LPAR rtas '%s'", filename);
 diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
 index a18446b..573c0b7 100644
 --- a/hw/ppc/spapr_events.c
 +++ b/hw/ppc/spapr_events.c
 @@ -212,6 +212,106 @@ struct hp_extended_log {
  struct rtas_event_log_v6_hp hp;
  } QEMU_PACKED;
  
 +struct rtas_event_log_v6_mc {
 +#define RTAS_LOG_V6_SECTION_ID_MC   0x4D43 /* MC */
 +struct rtas_event_log_v6_section_header hdr;
 +uint32_t fru_id;
 +uint32_t proc_id;
 +uint8_t error_type;
 +#define RTAS_LOG_V6_MC_TYPE_UE   0
 +#define RTAS_LOG_V6_MC_TYPE_SLB  1
 +#define RTAS_LOG_V6_MC_TYPE_ERAT 2
 +#define RTAS_LOG_V6_MC_TYPE_TLB  4
 +#define RTAS_LOG_V6_MC_TYPE_D_CACHE  5
 +#define RTAS_LOG_V6_MC_TYPE_I_CACHE  7
 +uint8_t sub_err_type;
 +#define RTAS_LOG_V6_MC_UE_INDETERMINATE  0
 +#define RTAS_LOG_V6_MC_UE_IFETCH 1
 +#define RTAS_LOG_V6_MC_UE_PAGE_TABLE_WALK_IFETCH 2
 +#define RTAS_LOG_V6_MC_UE_LOAD_STORE 3
 +#define RTAS_LOG_V6_MC_UE_PAGE_TABLE_WALK_LOAD_STORE 4
 +#define RTAS_LOG_V6_MC_SLB_PARITY0
 +#define RTAS_LOG_V6_MC_SLB_MULTIHIT  1
 +#define RTAS_LOG_V6_MC_SLB_INDETERMINATE 2
 +#define RTAS_LOG_V6_MC_ERAT_PARITY   1
 +#define RTAS_LOG_V6_MC_ERAT_MULTIHIT 

Re: [Qemu-devel] [PATCH 2/3] MAINTAINERS: Improve section headlines

[Stafford Horne]

On Mon, Jun 03, 2019 at 10:45:14AM +0200, Philippe Mathieu-Daudé wrote:
> On 5/31/19 5:36 AM, Stafford Horne wrote:
> > On Wed, May 29, 2019 at 05:08:52PM +0200, Markus Armbruster wrote:
> >> When scripts/get_maintainer.pl reports something like
> >>
> >> John Doe  (maintainer:Overall)
> >>
> >> the user is left to wonder *which* of our three "Overall" sections
> >> applies.  We have three, one each under "Guest CPU cores (TCG)",
> >> "Guest CPU Cores (KVM)", and "Overall usermode emulation".
> >>
> >> Rename sections under
> >>
> >> * "Guest CPU cores (TCG)" from "FOO" to "FOO CPU cores (TCG)"
> >>
> >> * "Guest CPU Cores (KVM)" from "FOO" to "FOO CPU cores (KVM)"
> >>
> >> * "Guest CPU Cores (Xen)" from "FOO" to "FOO CPU cores (Xen)"
> >>
> >> * "Architecture support" from "FOO" to "FOO general architecture
> >>   support"
> >>
> >> * "Tiny Code Generator (TCG)" from "FOO target" to "FOO TCG target"
> >>
> >> While there,
> >>
> >> Signed-off-by: Markus Armbruster 
> >> ---
> >>  MAINTAINERS | 78 ++---
> >>  1 file changed, 39 insertions(+), 39 deletions(-)
> > 
> > ... 
> > 
> >> -OpenRISC
> >> +OpenRISC CPU cores (TCG)
> >>  M: Stafford Horne 
> >>  S: Odd Fixes
> >>  F: target/openrisc/
> >>  F: hw/openrisc/
> >>  F: tests/tcg/openrisc/
> >>  
> > 
> > As directories listed there I look over both target/ (TCG?) and hw/.
> > Would it be better to be 'OpenRISC general architecture'?
> 
> There is a historical separation between target/ and hw/ because they
> cover different concepts, and have different maintainers/reviewers.
> 
> - target/$arch/ is for TCG/KVM
> - hw/ is for machines and their devices
>   (some devices are reused by multiple archs)
> 
> Although the separation is not always clear (some devices are tied to an
> architecture, some architecture instruction directly access devices) I'd
> prefer we keep 2 distincts MAINTAINERS sections (keeping you maintainer
> of both). This will ease developper with specific background/interests
> to volunteer to a particular section.

Hello,

Thanks for the explaination.  I think it makes sense to have 2 different
maintainer sections.  In that case should this patch be amended to move the
'F: hw/openrisc/' etc out to a different section with the different header?

-Stafford

Re: [Qemu-devel] [RFC PATCH 0/3] hw/display: Refresh UI depending on vGPU page flip events

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190604095847.10532-1-tina.zh...@intel.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  aarch64-softmmu/hw/display/virtio-gpu.o
  CC  arm-softmmu/hw/display/virtio-gpu-pci.o
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c: In function 
‘vfio_get_irq_info_cap’:
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:757:25: error: 
‘VFIO_IRQ_INFO_FLAG_CAPS’ undeclared (first use in this function); did you mean 
‘VFIO_REGION_INFO_FLAG_CAPS’?
  757 | if (!(info->flags & VFIO_IRQ_INFO_FLAG_CAPS)) {
  | ^~~
  | VFIO_REGION_INFO_FLAG_CAPS
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:757:25: note: each 
undeclared identifier is reported only once for each function it appears in
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:761:26: error: 
‘struct vfio_irq_info’ has no member named ‘cap_offset’
  761 | for (hdr = ptr + info->cap_offset; hdr != ptr; hdr = ptr + 
hdr->next) {
  |  ^~
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c: In function 
‘vfio_get_dev_irq_info’:
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:1636:44: error: 
‘VFIO_IRQ_INFO_CAP_TYPE’ undeclared (first use in this function); did you mean 
‘VFIO_REGION_INFO_CAP_TYPE’?
 1636 | hdr = vfio_get_irq_info_cap(*info, VFIO_IRQ_INFO_CAP_TYPE);
  |^~
  |VFIO_REGION_INFO_CAP_TYPE
In file included from 
/var/tmp/patchew-tester-tmp-ymcno5d3/src/include/qemu/osdep.h:51,
 from 
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:21:
/var/tmp/patchew-tester-tmp-ymcno5d3/src/include/qemu/compiler.h:57:34: error: 
dereferencing pointer to incomplete type ‘struct vfio_irq_info_cap_type’
   57 | const typeof(((type *) 0)->member) *__mptr = (ptr); \
  |  ^~
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:1642:20: note: in 
expansion of macro ‘container_of’
 1642 | cap_type = container_of(hdr, struct vfio_irq_info_cap_type, 
header);
  |^~~~
/var/tmp/patchew-tester-tmp-ymcno5d3/src/include/qemu/compiler.h:57:54: error: 
initialization of ‘const int *’ from incompatible pointer type ‘struct 
vfio_info_cap_header *’ [-Werror=incompatible-pointer-types]
   57 | const typeof(((type *) 0)->member) *__mptr = (ptr); \
  |  ^
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:1642:20: note: in 
expansion of macro ‘container_of’
---
 from 
/var/tmp/patchew-tester-tmp-ymcno5d3/src/include/glib-compat.h:32,
 from 
/var/tmp/patchew-tester-tmp-ymcno5d3/src/include/qemu/osdep.h:140,
 from 
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:21:
/var/tmp/patchew-tester-tmp-ymcno5d3/src/include/qemu/compiler.h:58:37: error: 
invalid use of undefined type ‘struct vfio_irq_info_cap_type’
   58 | (type *) ((char *) __mptr - offsetof(type, member));})
  | ^~~~
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:1642:20: note: in 
expansion of macro ‘container_of’
---
  CC  aarch64-softmmu/hw/timer/digic-timer.o
  CC  aarch64-softmmu/hw/timer/allwinner-a10-pit.o
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c: In function 
‘vfio_get_irq_info_cap’:
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:757:25: error: 
‘VFIO_IRQ_INFO_FLAG_CAPS’ undeclared (first use in this function); did you mean 
‘VFIO_REGION_INFO_FLAG_CAPS’?
  757 | if (!(info->flags & VFIO_IRQ_INFO_FLAG_CAPS)) {
  | ^~~
  | VFIO_REGION_INFO_FLAG_CAPS
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:757:25: note: each 
undeclared identifier is reported only once for each function it appears in
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c:761:26: error: 
‘struct vfio_irq_info’ has no member named ‘cap_offset’
  761 | for (hdr = ptr + info->cap_offset; hdr != ptr; hdr = ptr + 
hdr->next) {
  |  ^~
/var/tmp/patchew-tester-tmp-ymcno5d3/src/hw/vfio/common.c: In function 
‘vfio_get_dev_irq_info’:
/var/tm

Re: [Qemu-devel] [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load

[Igor Mammedov]

On Mon,  3 Jun 2019 16:01:20 +0100
Alex Bennée  wrote:

> When running on 32 bit TCG backends a wide unaligned load ends up
> truncating data before returning to the guest. We specifically have
> the return type as uint64_t to avoid any premature truncation so we
> should use the same for the interim types.
> 
> Hopefully fixes #1830872
> 
> Signed-off-by: Alex Bennée 

Fixes arm/virt bios-tables-test for me, so

Tested-by: Igor Mammedov 

> ---
>  accel/tcg/cputlb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
> index cdcc3771020..b796ab1cbea 100644
> --- a/accel/tcg/cputlb.c
> +++ b/accel/tcg/cputlb.c
> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, 
> TCGMemOpIdx oi,
>  && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
>  >= TARGET_PAGE_SIZE)) {  
>  target_ulong addr1, addr2;
> -tcg_target_ulong r1, r2;
> +uint64_t r1, r2;
>  unsigned shift;
>  do_unaligned_access:
>  addr1 = addr & ~(size - 1);

[Qemu-devel] [PATCH 3/3] qemu-bridge-helper: Document known shortcomings

[Markus Armbruster]

Signed-off-by: Markus Armbruster 
---
 qemu-bridge-helper.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
index f9940deefd..95624bc300 100644
--- a/qemu-bridge-helper.c
+++ b/qemu-bridge-helper.c
@@ -10,7 +10,17 @@
  *
  * This work is licensed under the terms of the GNU GPL, version 2.  See
  * the COPYING file in the top-level directory.
- *
+ */
+
+/*
+ * Known shortcomings:
+ * - There is no manual page
+ * - The syntax of the ACL file is not documented anywhere
+ * - parse_acl_file() doesn't report fopen() failure properly, fails
+ *   to check ferror() after fgets() failure, arbitrarily truncates
+ *   long lines, handles whitespace inconsistently, error messages
+ *   don't point to the offending file and line, errors in included
+ *   files are reported, but otherwise ignored, ...
  */
 
 #include "qemu/osdep.h"
-- 
2.21.0

[Qemu-devel] [PATCH 2/3] net: Deprecate tap backend's parameter "helper"

[Markus Armbruster]

-netdev tap,helper=... is a useless duplicate of -netdev bridge.
Deprecate and de-document.

Signed-off-by: Markus Armbruster 
---
 qapi/net.json|  3 ++-
 qemu-deprecated.texi |  4 
 qemu-options.hx  | 18 ++
 3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/qapi/net.json b/qapi/net.json
index 5f7bff1637..59d79a1ae1 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -221,7 +221,8 @@
 #
 # @br: bridge name (since 2.8)
 #
-# @helper: command to execute to configure bridge
+# @helper: command to execute to configure bridge (deprecated, use
+# type 'bridge' instead)
 #
 # @sndbuf: send buffer limit. Understands [TGMKkb] suffixes.
 #
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 50292d820b..52e7600ebc 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -48,6 +48,10 @@ for these file types is 'host_cdrom' or 'host_device' as 
appropriate.
 The @option{name} parameter of the @option{-net} option is a synonym
 for the @option{id} parameter, which should now be used instead.
 
+@subsection -netdev tap,helper=... (since 4.1)
+
+Use -netdev bridge instead.
+
 @subsection -smp (invalid topologies) (since 3.1)
 
 CPU topology properties should describe whole machine topology including
diff --git a/qemu-options.hx b/qemu-options.hx
index 39dc170429..3324203b51 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2121,7 +2121,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
 "configure a host TAP network backend with ID 'str'\n"
 #else
 "-netdev 
tap,id=str[,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile]\n"
-" 
[,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off]\n"
+" [,br=bridge][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off]\n"
 " 
[,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n]\n"
 " [,poll-us=n]\n"
 "configure a host TAP network backend with ID 'str'\n"
@@ -2130,8 +2130,6 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
 "to configure it and 'dfile' (default=" 
DEFAULT_NETWORK_DOWN_SCRIPT ")\n"
 "to deconfigure it\n"
 "use '[down]script=no' to disable script execution\n"
-"use network helper 'helper' (default=" 
DEFAULT_BRIDGE_HELPER ") to\n"
-"configure it\n"
 "use 'fd=h' to connect to an already opened TAP 
interface\n"
 "use 'fds=x:y:...:z' to connect to already opened 
multiqueue capable TAP interfaces\n"
 "use 'sndbuf=nbytes' to limit the size of the send buffer 
(the\n"
@@ -2435,7 +2433,7 @@ qemu-system-i386 -nic  
'user,id=n1,guestfwd=tcp:10.0.2.100:1234-cmd:netcat 10.10
 
 @end table
 
-@item -netdev 
tap,id=@var{id}[,fd=@var{h}][,ifname=@var{name}][,script=@var{file}][,downscript=@var{dfile}][,br=@var{bridge}][,helper=@var{helper}]
+@item -netdev 
tap,id=@var{id}[,fd=@var{h}][,ifname=@var{name}][,script=@var{file}][,downscript=@var{dfile}][,br=@var{bridge}]
 Configure a host TAP network backend with ID @var{id}.
 
 Use the network script @var{file} to configure it and the network script
@@ -2445,11 +2443,6 @@ automatically provides one. The default network 
configure script is
 @file{/etc/qemu-ifdown}. Use @option{script=no} or @option{downscript=no}
 to disable script execution.
 
-If running QEMU as an unprivileged user, use the network helper
-@var{helper} to configure the TAP interface and attach it to the bridge.
-The default network helper executable is @file{/path/to/qemu-bridge-helper}
-and the default bridge device is @file{br0}.
-
 @option{fd}=@var{h} can be used to specify the handle of an already
 opened host TAP interface.
 
@@ -2468,13 +2461,6 @@ qemu-system-i386 linux.img \
 -netdev tap,id=nd1,ifname=tap1 -device rtl8139,netdev=nd1
 @end example
 
-@example
-#launch a QEMU instance with the default network helper to
-#connect a TAP device to bridge br0
-qemu-system-i386 linux.img -device virtio-net-pci,netdev=n1 \
--netdev tap,id=n1,"helper=/path/to/qemu-bridge-helper"
-@end example
-
 @item -netdev bridge,id=@var{id}[,br=@var{bridge}][,helper=@var{helper}]
 Connect a host TAP network interface to a host bridge device.
 
-- 
2.21.0

[Qemu-devel] [PATCH 1/3] MAINTAINERS: Add qemu-bridge-helper.c to "Network device backends"

[Markus Armbruster]

Signed-off-by: Markus Armbruster 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a96829ea83..8b73f1f0d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1936,6 +1936,7 @@ M: Jason Wang 
 S: Maintained
 F: net/
 F: include/net/
+F: qemu-bridge-helper.c
 T: git https://github.com/jasowang/qemu.git net
 F: qapi/net.json
 
-- 
2.21.0

[Qemu-devel] [PATCH 0/3] Some qemu-bridge-helper work

[Markus Armbruster]

Markus Armbruster (3):
  MAINTAINERS: Add qemu-bridge-helper.c to "Network device backends"
  net: Deprecate tap backend's parameter "helper"
  qemu-bridge-helper: Document known shortcomings

 MAINTAINERS  |  1 +
 qapi/net.json|  3 ++-
 qemu-bridge-helper.c | 12 +++-
 qemu-deprecated.texi |  4 
 qemu-options.hx  | 18 ++
 5 files changed, 20 insertions(+), 18 deletions(-)

-- 
2.21.0

Re: [Qemu-devel] [PATCH v6 2/2] tests: acpi: add simple arm/virt testcase

[Igor Mammedov]

On Mon, 3 Jun 2019 18:08:12 +0200
Laszlo Ersek  wrote:

> On 06/03/19 13:22, Igor Mammedov wrote:
> > adds simple arm/virt test case that starts guest with
> > bios-tables-test.aarch64.iso.qcow2 boot image which
> > initializes UefiTestSupport* structure in RAM once
> > guest is booted.
> > 
> >  * see commit: tests: acpi: add acpi_find_rsdp_address_uefi() helper
> > 
> > Signed-off-by: Igor Mammedov 
> > ---
> > v6:
> >   * Since aarch64 TCG is broken on 32 bit arm host,
> > blacklist it till it's fixed
> >   * add aarch64 to rebuild script list
> > v4:
> >   * force test to use TCG accelerator
> > v3:
> >   * use firmware blobs directly from pc-bios directory
> >   * use bios-tables-test.aarch64.iso.qcow2 as test boot image
> >   * drop leftover qtest-uefi-images-aarch64 iMakefile rule from
> > previos version (Laszlo)
> >   * add Makefile rule to include bios-tables-test into
> > check-qtest-aarch64 target
> > v2:
> >   * specify in test_data where board's RAM starts and RAM size
> > 
> >  tests/Makefile.include  |  4 
> >  tests/bios-tables-test.c| 18 ++
> >  tests/data/acpi/rebuild-expected-aml.sh |  2 +-
> >  3 files changed, 23 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tests/Makefile.include b/tests/Makefile.include
> > index 1865f6b..2334969 100644
> > --- a/tests/Makefile.include
> > +++ b/tests/Makefile.include
> > @@ -267,6 +267,10 @@ check-qtest-arm-y += tests/hexloader-test$(EXESUF)
> >  check-qtest-aarch64-y = tests/numa-test$(EXESUF)
> >  check-qtest-aarch64-y += tests/boot-serial-test$(EXESUF)
> >  check-qtest-aarch64-y += tests/migration-test$(EXESUF)
> > +# TODO: once aarch64 TCG is fixed on ARM 32 bit host, make test 
> > unconditional  
> 
> I think you could also capture the following link here, in a comment:
> 
> # https://bugs.launchpad.net/qemu/+bug/1830872
Michael,
 could you fix it up on commit?
or we could merge v4
   [PATCH v4 13/15] tests: acpi: add simple arm/virt  testcase
which is the same modulo this blacklisting hunk, if
   [RFC PATCH] cputlb: use uint64_t for interim values  for unaligned load
fix is used as prerequisite.

> 
> > +ifneq ($(ARCH),arm)  
> 
> Can we exclude all 32-bit host arches, not just ARM? The discussion in
> LP#1830872 indicates aarch64-on-i386 can fail too (not this specific
> guest payload FWIW, but the "tests/memory" test).
I'd guess it's topic for a separate discussion (considering bios-tables-test
isn't affected it's probably not upto me to pull this trigger).

> 
> Other than that:
> 
> Reviewed-by: Laszlo Ersek 
Thanks!

> 
> Thanks,
> Laszlo
> 
> 
> > +check-qtest-aarch64-y += tests/bios-tables-test$(EXESUF)
> > +endif
> >  
> >  check-qtest-microblazeel-y += $(check-qtest-microblaze-y)
> >  
> > diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
> > index 28d7d42..1242d63 100644
> > --- a/tests/bios-tables-test.c
> > +++ b/tests/bios-tables-test.c
> > @@ -830,6 +830,22 @@ static void test_acpi_piix4_tcg_dimm_pxm(void)
> >  test_acpi_tcg_dimm_pxm(MACHINE_PC);
> >  }
> >  
> > +static void test_acpi_virt_tcg(void)
> > +{
> > +test_data data = {
> > +.machine = "virt",
> > +.accel = "tcg",
> > +.uefi_fl1 = "pc-bios/edk2-aarch64-code.fd",
> > +.uefi_fl2 = "pc-bios/edk2-arm-vars.fd",
> > +.cd = 
> > "tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2",
> > +.ram_start = 0x4000ULL,
> > +.scan_len = 128ULL * 1024 * 1024,
> > +};
> > +
> > +test_acpi_one("-cpu cortex-a57", &data);
> > +free_test_data(&data);
> > +}
> > +
> >  int main(int argc, char *argv[])
> >  {
> >  const char *arch = qtest_get_arch();
> > @@ -858,6 +874,8 @@ int main(int argc, char *argv[])
> >  qtest_add_func("acpi/q35/numamem", test_acpi_q35_tcg_numamem);
> >  qtest_add_func("acpi/piix4/dimmpxm", test_acpi_piix4_tcg_dimm_pxm);
> >  qtest_add_func("acpi/q35/dimmpxm", test_acpi_q35_tcg_dimm_pxm);
> > +} else if (strcmp(arch, "aarch64") == 0) {
> > +qtest_add_func("acpi/virt", test_acpi_virt_tcg);
> >  }
> >  ret = g_test_run();
> >  boot_sector_cleanup(disk);
> > diff --git a/tests/data/acpi/rebuild-expected-aml.sh 
> > b/tests/data/acpi/rebuild-expected-aml.sh
> > index ff7e622..d285321 100755
> > --- a/tests/data/acpi/rebuild-expected-aml.sh
> > +++ b/tests/data/acpi/rebuild-expected-aml.sh
> > @@ -12,7 +12,7 @@
> >  # This work is licensed under the terms of the GNU GPLv2.
> >  # See the COPYING.LIB file in the top-level directory.
> >  
> > -qemu_bins="x86_64-softmmu/qemu-system-x86_64"
> > +qemu_bins="x86_64-softmmu/qemu-system-x86_64 
> > aarch64-softmmu/qemu-system-aarch64"
> >  
> >  if [ ! -e "tests/bios-tables-test" ]; then
> >  echo "Test: bios-tables-test is required! Run make check before this 
> > script."
> >   
> 

[Qemu-devel] [PATCH v6] iotests: test big qcow2 shrink

[Vladimir Sementsov-Ogievskiy]

This test checks bug in qcow2_process_discards, fixed by previous
commit.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

Hi all!

This is a continuation of 
 [PATCH v5 0/3] Fix overflow bug in qcow2 discard
Two first patches are in Kevin's block branch, and here is fixed third.

v6:
  calculate reduce of disk usage instead of printing qemu-img map -f raw,
  which makes output the same for xfs, tmpfs and ext4, at least it works
  for me.

Based-on: git://repo.or.cz/qemu/kevin.git block

 tests/qemu-iotests/250 | 78 ++
 tests/qemu-iotests/250.out | 16 
 tests/qemu-iotests/group   |  1 +
 3 files changed, 95 insertions(+)
 create mode 100755 tests/qemu-iotests/250
 create mode 100644 tests/qemu-iotests/250.out

diff --git a/tests/qemu-iotests/250 b/tests/qemu-iotests/250
new file mode 100755
index 00..c9c0a84a5a
--- /dev/null
+++ b/tests/qemu-iotests/250
@@ -0,0 +1,78 @@
+#!/usr/bin/env bash
+#
+# Test big discard in qcow2 shrink
+#
+# Copyright (c) 2019 Virtuozzo International GmbH. All rights reserved.
+#
+# 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 .
+#
+
+# creator
+owner=vsement...@virtuozzo.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+status=1   # failure is the default!
+
+_cleanup()
+{
+_cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt qcow2
+_supported_proto file
+_supported_os Linux
+
+# This test checks that qcow2_process_discards does not truncate a discard
+# request > 2G.
+# To reproduce bug we need to overflow int by one sequential discard, so we
+# need size > 2G, bigger cluster size (as with default 64k we may have maximum
+# of 512M sequential data, corresponding to one L1 entry), and we need some
+# data of the beginning of the disk mapped to the end of file to prevent
+# bdrv_co_truncate(bs->file) call in qcow2_co_truncate(), which might succeed
+# anyway.
+
+disk_usage()
+{
+du --block-size=1 $1 | awk '{print $1}'
+}
+
+size=2100M
+IMGOPTS="cluster_size=1M,preallocation=metadata"
+
+_make_test_img $size
+$QEMU_IO -c 'discard 0 10M' -c 'discard 2090M 10M' \
+ -c 'write 2090M 10M' -c 'write 0 10M' "$TEST_IMG" | _filter_qemu_io
+
+# Check that our trick with swapping first and last 10M chunks succeeded.
+# Otherwise test may pass even if bdrv_pdiscard() fails in
+# qcow2_process_discards()
+$QEMU_IMG map "$TEST_IMG" | _filter_testdir
+
+before=$(disk_usage "$TEST_IMG")
+$QEMU_IMG resize --shrink "$TEST_IMG" 5M
+after=$(disk_usage "$TEST_IMG")
+
+echo "Disk usage delta: $((before - after))"
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/250.out b/tests/qemu-iotests/250.out
new file mode 100644
index 00..f480fd273b
--- /dev/null
+++ b/tests/qemu-iotests/250.out
@@ -0,0 +1,16 @@
+QA output created by 250
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=2202009600 
preallocation=metadata
+discard 10485760/10485760 bytes at offset 0
+10 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+discard 10485760/10485760 bytes at offset 2191523840
+10 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 10485760/10485760 bytes at offset 2191523840
+10 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 10485760/10485760 bytes at offset 0
+10 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+Offset  Length  Mapped to   File
+0   0xa00x82f0  TEST_DIR/t.qcow2
+0x82a0  0xa00x50TEST_DIR/t.qcow2
+Image resized.
+Disk usage delta: 15728640
+*** done
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 88049ad46c..f3b6d601b2 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -262,6 +262,7 @@
 247 rw quick
 248 rw quick
 249 rw auto quick
+250 rw auto quick
 252 rw auto backing quick
 253 rw auto quick
 254 rw auto backing quick
-- 
2.18.0

[Qemu-devel] ping Re: [PATCH v6 0/7] NBD reconnect

[Vladimir Sementsov-Ogievskiy]

ping

11.04.2019 20:27, Vladimir Sementsov-Ogievskiy wrote:
> Here is NBD reconnect. Previously, if connection failed all current
> and future requests will fail. After the series, nbd-client driver
> will try to reconnect unlimited times. During first @reconnect-delay
> seconds of reconnecting all requests will wait for the connection,
> and if it is established requests will be resent. After
> @reconnect-delay period all requests will be failed (until successful
> reconnect).
> 
> v4->v6:
>   (some preparing patches from v4 was merged as v5)
> 01: new
> 02: new
> 03: - drop unused things
> - future states
> - future s/break/continue/
> 04: - fix typos
>  - s/3.1/4.1/
>  - set 0 as default
> 05: new
> 06: - new states and s/break/continue/ moved here from 03
>  - drop NBDClientSession.receiving, as now in_flight
>requests used instread
>  - add copyright
>  - go to NBD_CLIENT_CONNECTING_NOWAIT immediately if
>reconnect_delay is 0 (so, reconnect_delay moved to
>NBDClientSession)
>  - on close, do qemu_co_sleep_wake(client->connection_co),
>to not wait for reconnect loop iteration
>  - handle state transition to QUIT during reconnect loop
>(assert(nbd_client_connecting(s)) was bad idea)
>  - don't try to fail on protocol errors after
>nbd_client_connect, as we can't distinguish them
>  - decrement in_flight around reconnect sleep to make
>it possible to drain and exit during it
>(v4 was based on something before in_flight logic
> introduced into nbd-client)
>  - changed logic in nbd_client_attach_aio_context
> 07: - refactor, using log and qmp_log
>  - drop export name
>  - drop strange try/except
>  - add reconnect-delay option (as 0 is a default now)
> 
> 
> Vladimir Sementsov-Ogievskiy (7):
>block/nbd-client: split connection_co start out of nbd_client_connect
>block/nbd-client: use non-blocking io channel for nbd negotiation
>block/nbd-client: move from quit to state
>block/nbd: add cmdline and qapi parameter reconnect-delay
>qemu-coroutine-sleep: introduce qemu_co_sleep_wake
>block/nbd-client: nbd reconnect
>iotests: test nbd reconnect
> 
>   qapi/block-core.json  |  12 +-
>   block/nbd-client.h|  15 +-
>   include/block/nbd.h   |   3 +-
>   include/qemu/coroutine.h  |   6 +
>   block/nbd-client.c| 416 +-
>   block/nbd.c   |  16 +-
>   nbd/client.c  |  16 +-
>   qemu-nbd.c|   2 +-
>   util/qemu-coroutine-sleep.c   |  20 +-
>   tests/qemu-iotests/249|  63 +
>   tests/qemu-iotests/249.out|  10 +
>   tests/qemu-iotests/group  |   1 +
>   tests/qemu-iotests/iotests.py |   4 +
>   13 files changed, 468 insertions(+), 116 deletions(-)
>   create mode 100755 tests/qemu-iotests/249
>   create mode 100644 tests/qemu-iotests/249.out
> 


-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH v1] linux-user: elf: ELF_HWCAP for s390x

[Laurent Vivier]

Le 04/06/2019 à 11:36, David Hildenbrand a écrit :
> Let's add all HWCAPs that we can support under TCG right now, when the
> respective CPU facilities are enabled.
> 
> Cc: Riku Voipio 
> Cc: Laurent Vivier 
> Cc: Cornelia Huck 
> Cc: Laurent Vivier 
> Cc: Richard Henderson 
> Signed-off-by: David Hildenbrand 
> ---
> 
> This patch is based on "[PATCH v2 00/22] s390x/tcg: Vector Instruction
> Support Part 4". I guess it is best if I just include it in my next
> pull request.
Based-on: <20190603090635.10631-1-da...@redhat.com>
  [PATCH v2 00/22] s390x/tcg: Vector Instruction Support Part 4

> 
> ---
>  include/elf.h|  1 +
>  linux-user/elfload.c | 39 +++
>  2 files changed, 40 insertions(+)
> 
> diff --git a/include/elf.h b/include/elf.h
> index ea7708a4ea..3501e0c8d0 100644
> --- a/include/elf.h
> +++ b/include/elf.h
> @@ -598,6 +598,7 @@ typedef struct {
>  #define HWCAP_S390_ETF3EH   256
>  #define HWCAP_S390_HIGH_GPRS512
>  #define HWCAP_S390_TE   1024
> +#define HWCAP_S390_VXRS 2048
>  
>  /* M68K specific definitions. */
>  /* We use the top 24 bits to encode information about the
> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> index a57b7049dd..59b813066c 100644
> --- a/linux-user/elfload.c
> +++ b/linux-user/elfload.c
> @@ -1308,6 +1308,45 @@ static inline void init_thread(struct target_pt_regs 
> *regs,
>  #define ELF_DATA ELFDATA2MSB
>  #define ELF_ARCH EM_S390
>  
> +#include "elf.h"
> +
> +#define ELF_HWCAP get_elf_hwcap()
> +
> +static uint32_t get_elf_hwcap(void)
> +{
> +uint32_t hwcap = 0;
> +
> +if (s390_has_feat(S390_FEAT_ESAN3)) {
> +hwcap |= HWCAP_S390_ESAN3;
> +}
> +if (s390_has_feat(S390_FEAT_ZARCH)) {
> +hwcap |= HWCAP_S390_ZARCH;
> +}
> +if (s390_has_feat(S390_FEAT_STFLE)) {
> +hwcap |= HWCAP_S390_STFLE;
> +}
> +if (s390_has_feat(S390_FEAT_MSA)) {
> +hwcap |= HWCAP_S390_MSA;
> +}
> +if (s390_has_feat(S390_FEAT_LONG_DISPLACEMENT)) {
> +hwcap |= HWCAP_S390_LDISP;
> +}
> +if (s390_has_feat(S390_FEAT_EXTENDED_IMMEDIATE)) {
> +hwcap |= HWCAP_S390_EIMM;
> +}
> +if (s390_has_feat(S390_FEAT_EXTENDED_TRANSLATION_3) &&
> +s390_has_feat(S390_FEAT_ETF3_ENH)) {
> +hwcap |= HWCAP_S390_ETF3EH;
> +}
> +/* 31-bit processes can use 64-bit registers */
> +hwcap |= HWCAP_S390_HIGH_GPRS;
> +if (s390_has_feat(S390_FEAT_VECTOR)) {
> +hwcap |= HWCAP_S390_VXRS;
> +}
> +
> +return hwcap;
> +}
> +
>  static inline void init_thread(struct target_pt_regs *regs, struct 
> image_info *infop)
>  {
>  regs->psw.addr = infop->entry;
> 

Acked-by: Laurent Vivier 

You can also do like the other architectures that use shortcuts like this:

#define GET_FEATURE(feat, hwcap) \
do { if (s390_has_feat(feat)) { hwcaps |= hwcap; } } while (0)
...
GET_FEATURE(S390_FEAT_VECTOR, HWCAP_S390_VXRS);
...


Thanks,
Laurent

[Qemu-devel] [PATCH v8 0/3] linux-user: A set of miscellaneous patches

[Aleksandar Markovic]

From: Aleksandar Markovic 

This is a collection of misc patches for Linux user that I recently
accumulated from variuous sources. All of them originate from problems
observed on mips target. However, these changes actually affect and fix
problems on multiple targets.

v7->v8:

  - added a patch on setsockopt() option SOL_ALG

v6->v7:

  - fixed a build error for older kernels related to the patch on
setsockopt() options
  - removed four patches that on the meantime got accepted into the
main source tree

v5->v6:

  - fixed a mistake in patch #4
  - improved commit messages in patches #4 and #6

v4->v5:

  - added the patch on statx() support
  - improved the patch on IPV6__MEMBERSHIP to take into
account the possibility of different names for a field
  - minor corrections in commit messages

v3->v4:

  - improved commit messages (fixed some typos, improved relevance)

v2->v3:

  - updated and improved commit messages
  - added IPV6_DROP_MEMBERSHIP support to the patch on setsockopt()'s
option

v1->v2:

  - added the patch on setsockopt()'s option IPV6_ADD_MEMBERSHIP
  - improved the commit me

Aleksandar Rikalo (1):
  linux-user: Add support for statx() syscall

Neng Chen (1):
  linux-user: Add support for setsockopt() options
IPV6__MEMBERSHIP

Yunqiang Su (1):
  linux-user: Add support for setsockopt() option SOL_ALG

 linux-user/syscall.c  | 192 +-
 linux-user/syscall_defs.h |  37 +
 2 files changed, 228 insertions(+), 1 deletion(-)

-- 
2.7.4

[Qemu-devel] [PATCH v8 2/3] linux-user: Add support for setsockopt() option SOL_ALG

[Aleksandar Markovic]

From: Yunqiang Su 

Add support for options SOL_ALG of the syscall setsockopt(). This
option is used in relation to Linux kernel Crypto API, and allows
a user to set additional information for the cipher operation via
syscall setsockopt(). The field "optname" must be one of the
following:

  - ALG_SET_KEY – seting the key
  - ALG_SET_AEAD_AUTHSIZE – set the authentication tag size

SOL_ALG is relatively newer setsockopt() option. Therefore, the
code that handles SOL_ALG is enclosed in "ifdef" so that the build
does not fail for older kernels that do not contain support for
SOL_ALG.

Signed-off-by: Yunqiang Su 
Signed-off-by: Aleksandar Markovic 
---
 linux-user/syscall.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index dde6889..7e41d74 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -1998,6 +1998,36 @@ static abi_long do_setsockopt(int sockfd, int level, int 
optname,
 goto unimplemented;
 }
 break;
+#ifdef SOL_ALG
+case SOL_ALG:
+switch (optname) {
+case ALG_SET_KEY:
+{
+char *alg_key = g_malloc(optlen);
+
+if (!alg_key) {
+return -TARGET_ENOMEM;
+}
+if (copy_from_user(alg_key, optval_addr, optlen)) {
+g_free(alg_key);
+return -TARGET_EFAULT;
+}
+ret = get_errno(setsockopt(sockfd, level, optname,
+   alg_key, optlen));
+g_free(alg_key);
+break;
+}
+case ALG_SET_AEAD_AUTHSIZE:
+{
+ret = get_errno(setsockopt(sockfd, level, optname,
+   NULL, optlen));
+break;
+}
+default:
+goto unimplemented;
+}
+break;
+#endif
 case TARGET_SOL_SOCKET:
 switch (optname) {
 case TARGET_SO_RCVTIMEO:
-- 
2.7.4

[Qemu-devel] [PATCH v8 1/3] linux-user: Add support for setsockopt() options IPV6__MEMBERSHIP

[Aleksandar Markovic]

From: Neng Chen 

Add support for options IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMPEMBERSHIP
of the syscall setsockopt(). These options control membership in
multicast groups. Their argument is a pointer to a struct ipv6_mreq,
which is in turn defined in IP v6 header netinet/in.h as:

 struct ipv6_mreq {
 /* IPv6 multicast address of group */
 struct  in6_addr  ipv6mr_multiaddr;
 /* local IPv6 address of interface */
 int ipv6mr_interface;
 };

...whereas its definition in kernel's include/uapi/linux/in6.h is:

 #if __UAPI_DEF_IPV6_MREQ
 struct ipv6_mreq {
 /* IPv6 multicast address of group */
 struct  in6_addr ipv6mr_multiaddr;
 /* local IPv6 address of interface */
 int ipv6mr_ifindex;
 };
 #endif

The first field of ipv6_mreq has the same name ("ipv6mr_multiaddr")
and type ("in6_addr") in both cases. Moreover, the in6_addr structure
consists of fields that are always big-endian (on host of any endian),
therefore the ipv6_mreq's field ipv6mr_multiaddr doesn't need any
endian conversion.

The second field of ipv6_mreq may, however, depending on the build
environment, have different names. This is the reason why the lines
"#if __UAPI_DEF_IPV6_MREQ" and "#if defined(__UAPI_DEF_IPV6_MREQ)"
are used in this patch - to establish the right choice for the field
name. Also, endian conversion is needed for this field, since it is
of type "int".

Signed-off-by: Neng Chen 
Signed-off-by: Aleksandar Markovic 
---
 linux-user/syscall.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 5e29e67..dde6889 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -1921,6 +1921,33 @@ static abi_long do_setsockopt(int sockfd, int level, int 
optname,
&pki, sizeof(pki)));
 break;
 }
+case IPV6_ADD_MEMBERSHIP:
+case IPV6_DROP_MEMBERSHIP:
+{
+struct ipv6_mreq ipv6mreq;
+
+if (optlen < sizeof(ipv6mreq)) {
+return -TARGET_EINVAL;
+}
+
+if (copy_from_user(&ipv6mreq, optval_addr, sizeof(ipv6mreq))) {
+return -TARGET_EFAULT;
+}
+
+#if defined(__UAPI_DEF_IPV6_MREQ)
+#if __UAPI_DEF_IPV6_MREQ
+ipv6mreq.ipv6mr_ifindex = tswap32(ipv6mreq.ipv6mr_ifindex);
+#else
+ipv6mreq.ipv6mr_interface = tswap32(ipv6mreq.ipv6mr_interface);
+#endif /* __UAPI_DEF_IVP6_MREQ */
+#else
+ipv6mreq.ipv6mr_interface = tswap32(ipv6mreq.ipv6mr_interface);
+#endif /* defined (__UAPI_DEF_IPV6_MREQ) */
+
+ret = get_errno(setsockopt(sockfd, level, optname,
+   &ipv6mreq, sizeof(ipv6mreq)));
+break;
+}
 default:
 goto unimplemented;
 }
-- 
2.7.4

Re: [Qemu-devel] [PATCH v1] linux-user: elf: ELF_HWCAP for s390x

[Richard Henderson]

On 6/4/19 4:36 AM, David Hildenbrand wrote:
> +if (s390_has_feat(S390_FEAT_ESAN3)) {
> +hwcap |= HWCAP_S390_ESAN3;
> +}
> +if (s390_has_feat(S390_FEAT_ZARCH)) {
> +hwcap |= HWCAP_S390_ZARCH;
> +}

While it's nice and symetrical testing these two features, I don't think they
can ever be false.

> +if (s390_has_feat(S390_FEAT_STFLE)) {
> +hwcap |= HWCAP_S390_STFLE;
> +}
> +if (s390_has_feat(S390_FEAT_MSA)) {
> +hwcap |= HWCAP_S390_MSA;
> +}
> +if (s390_has_feat(S390_FEAT_LONG_DISPLACEMENT)) {
> +hwcap |= HWCAP_S390_LDISP;
> +}
> +if (s390_has_feat(S390_FEAT_EXTENDED_IMMEDIATE)) {
> +hwcap |= HWCAP_S390_EIMM;
> +}
> +if (s390_has_feat(S390_FEAT_EXTENDED_TRANSLATION_3) &&
> +s390_has_feat(S390_FEAT_ETF3_ENH)) {
> +hwcap |= HWCAP_S390_ETF3EH;
> +}
> +/* 31-bit processes can use 64-bit registers */
> +hwcap |= HWCAP_S390_HIGH_GPRS;

And certainly this could never be set unless ZARCH, otherwise you have no
64-bit registers.  ;-)

So maybe clearer to just start with

  hwcap = HWCAP_S390_ESAN3 | HWCAP_S390_ZARCH | HWCAP_S390_HIGH_GPRS;

and continue from there.

Otherwise,
Reviewed-by: Richard Henderson 


r~

[Qemu-devel] [PATCH v8 3/3] linux-user: Add support for statx() syscall

[Aleksandar Markovic]

From: Aleksandar Rikalo 

Implement support for translation of system call statx(). The
implementation includes invoking other (more mature) system calls
(from the same 'stat' family) on the host side. This way, the
problems of potential lack of statx() availability of on the host
side are avoided.

Support for statx() in kernel and glibc was unfortunately introduced
in different points of time (the difference is more than a year):

  - kernel: Linux 4.11 (30 April 2017)
  - glibc: glibc 2.28 (1 Aug 2018)

In this patch, the availability of statx() support is established
via __NR_statx (if it is defined, statx() is considered available).
This coincedes with statx() introduction in kernel.

However, the structure statx definition may not be available for hosts
with glibc older than 2.28 (it is, by design, to be defined in one of
glibc headers), even though the full statx() functionality may be
supported in kernel, if the kernel is not older than 4.11. Hence,
a structure "target_statx" is defined in this patch, to remove that
dependency on glibc headers, and to use statx() functionality as soon
as the host kernel is capable of supporting it. Such structure statx
definition is used for both target and host structures statx (of
course, this doesn't mean the endian arrangement is the same on
target and host, and endian conversion is done in all necessary
cases).

Signed-off-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 linux-user/syscall.c  | 135 +-
 linux-user/syscall_defs.h |  37 +
 2 files changed, 171 insertions(+), 1 deletion(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 7e41d74..86d3522 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -6525,6 +6526,48 @@ static inline abi_long host_to_target_stat64(void 
*cpu_env,
 }
 #endif
 
+#if defined(TARGET_NR_statx) && defined(__NR_statx)
+static inline abi_long host_to_target_statx(struct target_statx *host_stx,
+abi_ulong target_addr)
+{
+struct target_statx *target_stx;
+
+if (!lock_user_struct(VERIFY_WRITE, target_stx, target_addr,  0)) {
+return -TARGET_EFAULT;
+}
+memset(target_stx, 0, sizeof(*target_stx));
+
+__put_user(host_stx->stx_mask, &target_stx->stx_mask);
+__put_user(host_stx->stx_blksize, &target_stx->stx_blksize);
+__put_user(host_stx->stx_attributes, &target_stx->stx_attributes);
+__put_user(host_stx->stx_nlink, &target_stx->stx_nlink);
+__put_user(host_stx->stx_uid, &target_stx->stx_uid);
+__put_user(host_stx->stx_gid, &target_stx->stx_gid);
+__put_user(host_stx->stx_mode, &target_stx->stx_mode);
+__put_user(host_stx->stx_ino, &target_stx->stx_ino);
+__put_user(host_stx->stx_size, &target_stx->stx_size);
+__put_user(host_stx->stx_blocks, &target_stx->stx_blocks);
+__put_user(host_stx->stx_attributes_mask, 
&target_stx->stx_attributes_mask);
+__put_user(host_stx->stx_atime.tv_sec, &target_stx->stx_atime.tv_sec);
+__put_user(host_stx->stx_atime.tv_nsec, &target_stx->stx_atime.tv_nsec);
+__put_user(host_stx->stx_btime.tv_sec, &target_stx->stx_atime.tv_sec);
+__put_user(host_stx->stx_btime.tv_nsec, &target_stx->stx_atime.tv_nsec);
+__put_user(host_stx->stx_ctime.tv_sec, &target_stx->stx_atime.tv_sec);
+__put_user(host_stx->stx_ctime.tv_nsec, &target_stx->stx_atime.tv_nsec);
+__put_user(host_stx->stx_mtime.tv_sec, &target_stx->stx_atime.tv_sec);
+__put_user(host_stx->stx_mtime.tv_nsec, &target_stx->stx_atime.tv_nsec);
+__put_user(host_stx->stx_rdev_major, &target_stx->stx_rdev_major);
+__put_user(host_stx->stx_rdev_minor, &target_stx->stx_rdev_minor);
+__put_user(host_stx->stx_dev_major, &target_stx->stx_dev_major);
+__put_user(host_stx->stx_dev_minor, &target_stx->stx_dev_minor);
+
+unlock_user_struct(target_stx, target_addr, 1);
+
+return 0;
+}
+#endif
+
+
 /* ??? Using host futex calls even when target atomic operations
are not really atomic probably breaks things.  However implementing
futexes locally would make futexes shared between multiple processes
@@ -7103,7 +7146,8 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
 abi_long ret;
 #if defined(TARGET_NR_stat) || defined(TARGET_NR_stat64) \
 || defined(TARGET_NR_lstat) || defined(TARGET_NR_lstat64) \
-|| defined(TARGET_NR_fstat) || defined(TARGET_NR_fstat64)
+|| defined(TARGET_NR_fstat) || defined(TARGET_NR_fstat64) \
+|| defined(TARGET_NR_statx)
 struct stat st;
 #endif
 #if defined(TARGET_NR_statfs) || defined(TARGET_NR_statfs64) \
@@ -10181,6 +10225,95 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
 ret = host_to_target_stat64(cpu_env, arg3, &st);
 return ret;
 #endif
+#if defined(TARGET_NR_statx)
+case TARGET_NR_statx:
+

[Qemu-devel] How can i run different router or switch on qemu

[Michael.Jacky via Qemu-devel]

Hello,
I'm sorry to waste your time.
Now I have a question and i can't find answer by google.
I need to use qemu to run different router,switch,and different 
type(example:cisco,netgear,forti and more) and use openstack vm to connect 
these equipment.
I found these equipment with different type,for example .bin,.img,and different 
equipment directory structure is different.
How can i run these equipments on qemu and what i need to do first.
Thank you very much.

Re: [Qemu-devel] [PATCH 1/7] virtio-pmem: add virtio device

[Cornelia Huck]

On Thu, 23 May 2019 15:54:43 +0530
Pankaj Gupta  wrote:

> This is the implementation of virtio-pmem device. Support will require
> machine changes for the architectures that will support it, so it will
> not yet be compiled. It can be unlocked with VIRTIO_PMEM_SUPPORTED per
> machine and disabled globally via VIRTIO_PMEM.
> 
> We cannot use the "addr" property as that is already used e.g. for
> virtio-pci/pci devices. And we will have e.g. virtio-pmem-pci as a proxy.
> So we have to choose a different one (unfortunately). "memaddr" it is.
> That name should ideally be used by all other virtio-* based memory
> devices in the future.
> -device virtio-pmem-pci,id=p0,bus=bux0,addr=0x01,memaddr=0x100...
> 
> Acked-by: Markus Armbruster 
> [ QAPI bits ]
> Signed-off-by: Pankaj Gupta 
> [ MemoryDevice/MemoryRegion changes, cleanups, addr property "memaddr",
>   split up patches, unplug handler ]
> Signed-off-by: David Hildenbrand 
> ---
>  hw/virtio/Kconfig   |  10 +++
>  hw/virtio/Makefile.objs |   1 +
>  hw/virtio/virtio-pmem.c | 190 
> 
>  include/hw/virtio/virtio-pmem.h |  49 +++
>  qapi/misc.json  |  28 +-
>  5 files changed, 277 insertions(+), 1 deletion(-)
>  create mode 100644 hw/virtio/virtio-pmem.c
>  create mode 100644 include/hw/virtio/virtio-pmem.h

> diff --git a/hw/virtio/virtio-pmem.c b/hw/virtio/virtio-pmem.c
> new file mode 100644
> index 00..c462d2c942
> --- /dev/null
> +++ b/hw/virtio/virtio-pmem.c
> @@ -0,0 +1,190 @@

> +static void virtio_pmem_unrealize(DeviceState *dev, Error **errp)
> +{
> +VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> +VirtIOPMEM *pmem = VIRTIO_PMEM(dev);
> +
> +host_memory_backend_set_mapped(pmem->memdev, false);
> +pmem->rq_vq = virtio_add_queue(vdev, 128, virtio_pmem_flush);

Adding a queue during unrealize looks weird... copy/paste error?

> +virtio_cleanup(vdev);
> +}

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

[Kevin Wolf]

Am 04.06.2019 um 11:13 hat Klaus Birkelund geschrieben:
> On Tue, Jun 04, 2019 at 10:46:45AM +0200, Kevin Wolf wrote:
> > Am 04.06.2019 um 10:28 hat Klaus Birkelund geschrieben:
> > > On Mon, Jun 03, 2019 at 09:30:53AM -0600, Heitke, Kenneth wrote:
> > > > 
> > > > 
> > > > On 6/3/2019 5:14 AM, Kevin Wolf wrote:
> > > > > Am 28.05.2019 um 08:18 hat Klaus Birkelund geschrieben:
> > > > > > On Mon, May 20, 2019 at 11:40:30AM -0600, Kenneth Heitke wrote:
> > > > > > > Signed-off-by: Kenneth Heitke 
> > > > > 
> > > > > > > diff --git a/hw/block/nvme.h b/hw/block/nvme.h
> > > > > > > index 56c9d4b4b1..d7277e72b7 100644
> > > > > > > --- a/hw/block/nvme.h
> > > > > > > +++ b/hw/block/nvme.h
> > > > > > > @@ -69,6 +69,7 @@ typedef struct NvmeCtrl {
> > > > > > >   uint16_tmax_prp_ents;
> > > > > > >   uint16_tcqe_size;
> > > > > > >   uint16_tsqe_size;
> > > > > > > +uint16_toncs;
> > > > > > 
> > > > > > Looks like this unused member snuck its way into the patch. But I 
> > > > > > see no
> > > > > > harm in it being there.
> > > > > 
> > > > > Good catch. I'll just remove it again from my branch.
> > > > > 
> > > > > > > +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);
> > > > > 
> > > > > Here I wonder why we use QEMU_CLOCK_REALTIME in a device emulation.
> > > > > Wouldn't QEMU_CLOCK_VIRTUAL make more sense?
> > > > > 
> > > > 
> > > > QEMU_CLOCK_VIRTUAL probably would make more sense. When I was reading
> > > > through the differences I wasn't really sure what to pick. iven that 
> > > > this is
> > > > the time within the device's context, the virtual time seems more 
> > > > correct.
> > > > 
> > >  
> > > I thought about this too when I reviewed, but came to the conclusion
> > > that REALTIME was correct. The timestamp is basically a value that the
> > > host stores in the controller. When the host uses Get Features to get
> > > the the current time it would expect it to match the progression for its
> > > own wall clockright? If I understand REALTIME vs VIRTUAL correctly,
> > > using VIRTUAL, it would go way out of sync.
> > 
> > Which two things would go out of sync with VIRTUAL?
> > 
> > Not an expert on clocks myself, but I think the main question is what
> > happens to the clock while the VM is stopped. REALTIME continues running
> > where as VIRTUAL is stopped. If we expose REALTIME measurements to the
> > guest, the time passed may look a lot longer than what the guest's clock
> > actually says. So this is the thing I am worried would go out of sync
> > with REALTIME.
> > 
> 
> OK, fair point.
> 
> Thinking about this some more, I agree that VIRTUAL is more correct. An
> application should never track elapsed time using real wall clock time,
> but some monotonic clock that is oblivious to say NTP adjustments.

Thanks. I'll fix up the patch accordingly.

Kevin

Re: [Qemu-devel] [PATCH v6] iotests: test big qcow2 shrink

[Kevin Wolf]

Am 04.06.2019 um 14:39 hat Vladimir Sementsov-Ogievskiy geschrieben:
> This test checks bug in qcow2_process_discards, fixed by previous
> commit.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 

Thanks, applied to the block branch.

Kevin

Re: [Qemu-devel] [PATCH v1] linux-user: elf: ELF_HWCAP for s390x

[David Hildenbrand]

On 04.06.19 14:54, Laurent Vivier wrote:
> Le 04/06/2019 à 11:36, David Hildenbrand a écrit :
>> Let's add all HWCAPs that we can support under TCG right now, when the
>> respective CPU facilities are enabled.
>>
>> Cc: Riku Voipio 
>> Cc: Laurent Vivier 
>> Cc: Cornelia Huck 
>> Cc: Laurent Vivier 
>> Cc: Richard Henderson 
>> Signed-off-by: David Hildenbrand 
>> ---
>>
>> This patch is based on "[PATCH v2 00/22] s390x/tcg: Vector Instruction
>> Support Part 4". I guess it is best if I just include it in my next
>> pull request.
> Based-on: <20190603090635.10631-1-da...@redhat.com>
>   [PATCH v2 00/22] s390x/tcg: Vector Instruction Support Part 4
> 
>>
>> ---
>>  include/elf.h|  1 +
>>  linux-user/elfload.c | 39 +++
>>  2 files changed, 40 insertions(+)
>>
>> diff --git a/include/elf.h b/include/elf.h
>> index ea7708a4ea..3501e0c8d0 100644
>> --- a/include/elf.h
>> +++ b/include/elf.h
>> @@ -598,6 +598,7 @@ typedef struct {
>>  #define HWCAP_S390_ETF3EH   256
>>  #define HWCAP_S390_HIGH_GPRS512
>>  #define HWCAP_S390_TE   1024
>> +#define HWCAP_S390_VXRS 2048
>>  
>>  /* M68K specific definitions. */
>>  /* We use the top 24 bits to encode information about the
>> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
>> index a57b7049dd..59b813066c 100644
>> --- a/linux-user/elfload.c
>> +++ b/linux-user/elfload.c
>> @@ -1308,6 +1308,45 @@ static inline void init_thread(struct target_pt_regs 
>> *regs,
>>  #define ELF_DATAELFDATA2MSB
>>  #define ELF_ARCHEM_S390
>>  
>> +#include "elf.h"
>> +
>> +#define ELF_HWCAP get_elf_hwcap()
>> +
>> +static uint32_t get_elf_hwcap(void)
>> +{
>> +uint32_t hwcap = 0;
>> +
>> +if (s390_has_feat(S390_FEAT_ESAN3)) {
>> +hwcap |= HWCAP_S390_ESAN3;
>> +}
>> +if (s390_has_feat(S390_FEAT_ZARCH)) {
>> +hwcap |= HWCAP_S390_ZARCH;
>> +}
>> +if (s390_has_feat(S390_FEAT_STFLE)) {
>> +hwcap |= HWCAP_S390_STFLE;
>> +}
>> +if (s390_has_feat(S390_FEAT_MSA)) {
>> +hwcap |= HWCAP_S390_MSA;
>> +}
>> +if (s390_has_feat(S390_FEAT_LONG_DISPLACEMENT)) {
>> +hwcap |= HWCAP_S390_LDISP;
>> +}
>> +if (s390_has_feat(S390_FEAT_EXTENDED_IMMEDIATE)) {
>> +hwcap |= HWCAP_S390_EIMM;
>> +}
>> +if (s390_has_feat(S390_FEAT_EXTENDED_TRANSLATION_3) &&
>> +s390_has_feat(S390_FEAT_ETF3_ENH)) {
>> +hwcap |= HWCAP_S390_ETF3EH;
>> +}
>> +/* 31-bit processes can use 64-bit registers */
>> +hwcap |= HWCAP_S390_HIGH_GPRS;
>> +if (s390_has_feat(S390_FEAT_VECTOR)) {
>> +hwcap |= HWCAP_S390_VXRS;
>> +}
>> +
>> +return hwcap;
>> +}
>> +
>>  static inline void init_thread(struct target_pt_regs *regs, struct 
>> image_info *infop)
>>  {
>>  regs->psw.addr = infop->entry;
>>
> 
> Acked-by: Laurent Vivier 
> 
> You can also do like the other architectures that use shortcuts like this:
> 
> #define GET_FEATURE(feat, hwcap) \
> do { if (s390_has_feat(feat)) { hwcaps |= hwcap; } } while (0)
> ...
> GET_FEATURE(S390_FEAT_VECTOR, HWCAP_S390_VXRS);
> ...

Thanks, I'll use this.

Cheers!

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v1] linux-user: elf: ELF_HWCAP for s390x

[David Hildenbrand]

On 04.06.19 15:00, Richard Henderson wrote:
> On 6/4/19 4:36 AM, David Hildenbrand wrote:
>> +if (s390_has_feat(S390_FEAT_ESAN3)) {
>> +hwcap |= HWCAP_S390_ESAN3;
>> +}
>> +if (s390_has_feat(S390_FEAT_ZARCH)) {
>> +hwcap |= HWCAP_S390_ZARCH;
>> +}
> 
> While it's nice and symetrical testing these two features, I don't think they
> can ever be false.
> 
>> +if (s390_has_feat(S390_FEAT_STFLE)) {
>> +hwcap |= HWCAP_S390_STFLE;
>> +}
>> +if (s390_has_feat(S390_FEAT_MSA)) {
>> +hwcap |= HWCAP_S390_MSA;
>> +}
>> +if (s390_has_feat(S390_FEAT_LONG_DISPLACEMENT)) {
>> +hwcap |= HWCAP_S390_LDISP;
>> +}
>> +if (s390_has_feat(S390_FEAT_EXTENDED_IMMEDIATE)) {
>> +hwcap |= HWCAP_S390_EIMM;
>> +}
>> +if (s390_has_feat(S390_FEAT_EXTENDED_TRANSLATION_3) &&
>> +s390_has_feat(S390_FEAT_ETF3_ENH)) {
>> +hwcap |= HWCAP_S390_ETF3EH;
>> +}
>> +/* 31-bit processes can use 64-bit registers */
>> +hwcap |= HWCAP_S390_HIGH_GPRS;
> 
> And certainly this could never be set unless ZARCH, otherwise you have no
> 64-bit registers.  ;-)
> 
> So maybe clearer to just start with
> 
>   hwcap = HWCAP_S390_ESAN3 | HWCAP_S390_ZARCH | HWCAP_S390_HIGH_GPRS;

Makes sense, and fits into a single line ;)

Thanks!

> 
> and continue from there.
> 
> Otherwise,
> Reviewed-by: Richard Henderson 
> 
> 
> r~
> 


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PULL 22/27] vl: Create block backends before setting machine properties

[Paolo Bonzini]

On 03/06/19 19:40, Markus Armbruster wrote:
> 
> Paolo, why is pr-manager-helper a delayed object?  Why this hunk of
> commit 7c9e527659c:
> 
> diff --git a/vl.c b/vl.c
> index 9bb5058c3a..a121a65731 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2893,7 +2893,8 @@ static int machine_set_property(void *opaque,
>   */
>  static bool object_create_initial(const char *type)
>  {
> -if (g_str_equal(type, "rng-egd")) {
> +if (g_str_equal(type, "rng-egd") ||
> +g_str_has_prefix(type, "pr-manager-")) {
>  return false;
>  }
> 

I don't think there was any particular reason.  Change it back to
normal, I can send a pull request today for that.

Paolo

Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support

[Jens Freimann]

On Mon, Jun 03, 2019 at 04:36:48PM -0300, Eduardo Habkost wrote:

On Mon, Jun 03, 2019 at 10:24:56AM +0200, Jens Freimann wrote:

On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote:
> On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote:
> > On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote:
> > > On Tue, May 21, 2019 at 10:45:05AM +0100, Dr. David Alan Gilbert wrote:
> > > > * Jens Freimann (jfreim...@redhat.com) wrote:
Why is it bad to fully re-create the device in case of a failed migration?


Bad or not, I thought the whole point of doing it inside QEMU was
to do something libvirt wouldn't be able to do (namely,
unplugging the device while not freeing resources).  If we are
doing something that management software is already capable of
doing, what's the point?


Event though management software seems to be capable of it, a failover
implementation has never happened. As Michael says network failover is
a mechanism (there's no good reason not to use a PT device if it is
available), not a policy. We are now trying to implement it in a
simple way, contained within QEMU. 


Quoting a previous message from this thread:

On Thu, May 30, 2019 at 02:09:42PM -0400, Michael S. Tsirkin wrote:
| > On Thu, May 30, 2019 at 07:00:23PM +0100, Dr. David Alan Gilbert wrote:
| > >  This patch series is very
| > > odd precisely because it's trying to do the unplug itself in the
| > > migration phase rather than let the management layer do it - so unless
| > > it's nailed down how to make sure that's really really bullet proof
| > > then we've got to go back and ask the question about whether we should
| > > really fix it so it can be done by the management layer.
| > >
| > > Dave
| >
| > management already said they can't because files get closed and
| > resources freed on unplug and so they might not be able to re-add device
| > on migration failure. We do it in migration because that is
| > where failures can happen and we can recover.


This is something that I can work on as well, but it doesn't have to
be part of this patch set in my opinion. Let's say migration fails and we can't
re-plug the primary device. We can still use the standby (virtio-net)
device which would only mean slower networking. How likely is it that
the primary device is grabbed by another VM between unplugging and
migration failure anyway? 


regards,
Jens 





--
Eduardo

Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support

[Eduardo Habkost]

On Tue, Jun 04, 2019 at 03:43:21PM +0200, Jens Freimann wrote:
> On Mon, Jun 03, 2019 at 04:36:48PM -0300, Eduardo Habkost wrote:
> > On Mon, Jun 03, 2019 at 10:24:56AM +0200, Jens Freimann wrote:
> > > On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote:
> > > > On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote:
> > > > > On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote:
> > > > > > On Tue, May 21, 2019 at 10:45:05AM +0100, Dr. David Alan Gilbert 
> > > > > > wrote:
> > > > > > > * Jens Freimann (jfreim...@redhat.com) wrote:
> > > Why is it bad to fully re-create the device in case of a failed migration?
> > 
> > Bad or not, I thought the whole point of doing it inside QEMU was
> > to do something libvirt wouldn't be able to do (namely,
> > unplugging the device while not freeing resources).  If we are
> > doing something that management software is already capable of
> > doing, what's the point?
> 
> Event though management software seems to be capable of it, a failover
> implementation has never happened. As Michael says network failover is
> a mechanism (there's no good reason not to use a PT device if it is
> available), not a policy. We are now trying to implement it in a
> simple way, contained within QEMU.

I don't think this is a strong enough reason to move complexity
to QEMU.

This might look like it's reducing complexity in the
QEMU<->libvirt interface, but having QEMU unplugging/plugging
devices automatically without libvirt involvement is actually
complicating that interface.

That said, I won't try to prevent this from being merged if the
maintainers and libvirt developers agree on this interface.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v16 16/23] Add rx-softmmu

[Richard Henderson]

On 6/4/19 1:38 AM, Philippe Mathieu-Daudé wrote:
> Hi Richard,
> 
> On 5/31/19 3:43 PM, Richard Henderson wrote:
>> From: Yoshinori Sato 
>>
>> Tested-by: Philippe Mathieu-Daudé 
>> Reviewed-by: Philippe Mathieu-Daudé 
>> Signed-off-by: Yoshinori Sato 
>> Message-Id: <20190516055244.95559-10-ys...@users.sourceforge.jp>
>> Signed-off-by: Richard Henderson 
>> ---
>>  include/sysemu/arch_init.h | 1 +
>>  arch_init.c| 2 ++
>>  configure  | 8 
>>  default-configs/rx-softmmu.mak | 3 +++
>>  hw/Kconfig | 1 +
>>  5 files changed, 15 insertions(+)
>>  create mode 100644 default-configs/rx-softmmu.mak
>>
>> diff --git a/include/sysemu/arch_init.h b/include/sysemu/arch_init.h
>> index 10cbafe970..3f4f844f7b 100644
>> --- a/include/sysemu/arch_init.h
>> +++ b/include/sysemu/arch_init.h
>> @@ -25,6 +25,7 @@ enum {
>>  QEMU_ARCH_NIOS2 = (1 << 17),
>>  QEMU_ARCH_HPPA = (1 << 18),
>>  QEMU_ARCH_RISCV = (1 << 19),
>> +QEMU_ARCH_RX = (1 << 20),
>>  };
>>  
>>  extern const uint32_t arch_type;
>> diff --git a/arch_init.c b/arch_init.c
>> index f4f3f610c8..cc25ddd7ca 100644
>> --- a/arch_init.c
>> +++ b/arch_init.c
>> @@ -74,6 +74,8 @@ int graphic_depth = 32;
>>  #define QEMU_ARCH QEMU_ARCH_PPC
>>  #elif defined(TARGET_RISCV)
>>  #define QEMU_ARCH QEMU_ARCH_RISCV
>> +#elif defined(TARGET_RX)
>> +#define QEMU_ARCH QEMU_ARCH_RX
>>  #elif defined(TARGET_S390X)
>>  #define QEMU_ARCH QEMU_ARCH_S390X
>>  #elif defined(TARGET_SH4)
>> diff --git a/configure b/configure
>> index 6cdcfb2dc3..7e5477e487 100755
>> --- a/configure
>> +++ b/configure
>> @@ -7605,6 +7605,11 @@ case "$target_name" in
>>  gdb_xml_files="riscv-64bit-cpu.xml riscv-64bit-fpu.xml 
>> riscv-64bit-csr.xml"
>>  target_compiler=$cross_cc_riscv64
>>;;
>> +  rx)
>> +TARGET_ARCH=rx
>> +bflt="yes"
>> +target_compiler=$cross_cc_rx
>> +  ;;
>>sh4|sh4eb)
>>  TARGET_ARCH=sh4
>>  bflt="yes"
>> @@ -7825,6 +7830,9 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
>>riscv*)
>>  disas_config "RISCV"
>>;;
>> +  rx)
>> +disas_config "RX"
>> +  ;;
>>s390*)
>>  disas_config "S390"
>>;;
>> diff --git a/default-configs/rx-softmmu.mak b/default-configs/rx-softmmu.mak
>> new file mode 100644
>> index 00..a3eecefb11
>> --- /dev/null
>> +++ b/default-configs/rx-softmmu.mak
>> @@ -0,0 +1,3 @@
>> +# Default configuration for rx-softmmu
>> +
>> +CONFIG_RX_VIRT=y
>> diff --git a/hw/Kconfig b/hw/Kconfig
>> index 195f541e50..b0c7221240 100644
>> --- a/hw/Kconfig
>> +++ b/hw/Kconfig
>> @@ -54,6 +54,7 @@ source nios2/Kconfig
>>  source openrisc/Kconfig
>>  source ppc/Kconfig
>>  source riscv/Kconfig
>> +source rx/Kconfig
>>  source s390x/Kconfig
>>  source sh4/Kconfig
>>  source sparc/Kconfig
>>
> 
> Please squash in:
> 
> -- >8 --
> --- a/include/exec/poison.h
> +++ b/include/exec/poison.h
> @@ -26,6 +26,7 @@
>  #pragma GCC poison TARGET_PPC
>  #pragma GCC poison TARGET_PPC64
>  #pragma GCC poison TARGET_ABI32
> +#pragma GCC poison TARGET_RX
>  #pragma GCC poison TARGET_S390X
>  #pragma GCC poison TARGET_SH4
>  #pragma GCC poison TARGET_SPARC
> ---

Thanks, good catch.


r~

Re: [Qemu-devel] [PATCH v2 1/2] x86/cpu: Add support for UMONITOR/UMWAIT/TPAUSE

[Cornelia Huck]

On Fri, 24 May 2019 16:18:38 +0800
Tao Xu  wrote:

> UMONITOR, UMWAIT and TPAUSE are a set of user wait instructions.
> Availability of the user wait instructions is indicated by the presence
> of the CPUID feature flag WAITPKG CPUID.0x07.0x0:ECX[5].
> 
> The patch enable the umonitor, umwait and tpause features in KVM.
> Because umwait and tpause can put a (psysical) CPU into a power saving
> state, by default we dont't expose it in kvm and provide a capability to
> enable it. Use kvm capability to enable UMONITOR, UMWAIT and TPAUSE when
> QEMU use "-overcommit cpu-pm=on, a VM can use UMONITOR, UMWAIT and TPAUSE
> instructions. If the instruction causes a delay, the amount of time
> delayed is called here the physical delay. The physical delay is first
> computed by determining the virtual delay (the time to delay relative to
> the VM’s timestamp counter). Otherwise, UMONITOR, UMWAIT and TPAUSE cause
> an invalid-opcode exception(#UD).
> 
> The release document ref below link:
> https://software.intel.com/sites/default/files/\
> managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
> 
> Co-developed-by: Jingqi Liu 
> Signed-off-by: Jingqi Liu 
> Signed-off-by: Tao Xu 
> ---
>  linux-headers/linux/kvm.h |  1 +
>  target/i386/cpu.c |  3 ++-
>  target/i386/cpu.h |  1 +
>  target/i386/kvm.c | 13 +
>  4 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index c8423e760c..86cc2dbdd0 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -993,6 +993,7 @@ struct kvm_ppc_resize_hpt {
>  #define KVM_CAP_ARM_SVE 170
>  #define KVM_CAP_ARM_PTRAUTH_ADDRESS 171
>  #define KVM_CAP_ARM_PTRAUTH_GENERIC 172
> +#define KVM_CAP_ENABLE_USR_WAIT_PAUSE 173
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  

No comment on the actual change, but please split out any linux-header
changes so they can be replaced with a proper headers update when the
code is merged.

Re: [Qemu-devel] [PATCH v4 06/11] hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s) in ACPI HMAT

[Igor Mammedov]

On Wed,  8 May 2019 14:17:21 +0800
Tao Xu  wrote:

> From: Liu Jingqi 
> 
> This structure describes the memory access latency and bandwidth
> information from various memory access initiator proximity domains.
> The latency and bandwidth numbers represented in this structure
> correspond to rated latency and bandwidth for the platform.
> The software could use this information as hint for optimization.
> 
> Signed-off-by: Liu Jingqi 
> Signed-off-by: Tao Xu 
> ---
> 
> Changes in v4 -> v3:
> - use build_append_int_noprefix() to build System Locality Latency
> and Bandwidth Information Structure(s) tables (Igor)
> - move globals (hmat_lb_info) into MachineState (Igor)
> - move hmat_build_lb() inside of hmat_build_hma() (Igor)
> ---
>  hw/acpi/hmat.c  | 97 -
>  hw/acpi/hmat.h  | 39 +
>  include/hw/boards.h |  3 ++
>  include/qemu/typedefs.h |  1 +
>  include/sysemu/sysemu.h | 22 ++
>  5 files changed, 161 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
> index bffe453280..54aabf77eb 100644
> --- a/hw/acpi/hmat.c
> +++ b/hw/acpi/hmat.c
> @@ -29,6 +29,9 @@
>  #include "hw/acpi/hmat.h"
>  #include "hw/nvram/fw_cfg.h"
>  
> +static uint32_t initiator_pxm[MAX_NODES], target_pxm[MAX_NODES];
> +static uint32_t num_initiator, num_target;
> +
>  /* Build Memory Subsystem Address Range Structure */
>  static void build_hmat_spa(GArray *table_data, MachineState *ms,
> uint64_t base, uint64_t length, int node)
> @@ -77,6 +80,20 @@ static int pc_dimm_device_list(Object *obj, void *opaque)
>  return 0;
>  }
>  
> +static void classify_proximity_domains(MachineState *ms)
> +{
> +int node;
> +
> +for (node = 0; node < ms->numa_state->num_nodes; node++) {
> +if (ms->numa_state->nodes[node].is_initiator) {
> +initiator_pxm[num_initiator++] = node;
> +}
> +if (ms->numa_state->nodes[node].is_target) {
> +target_pxm[num_target++] = node;
> +}
> +}
> +}
> +
>  /*
>   * The Proximity Domain of System Physical Address ranges defined
>   * in the HMAT, NFIT and SRAT tables shall match each other.
> @@ -85,9 +102,10 @@ static void hmat_build_hma(GArray *table_data, 
> MachineState *ms)
>  {
>  GSList *device_list = NULL;
>  uint64_t mem_base, mem_len;
> -int i;
> +int i, j, hrchy, type;
>  uint32_t mem_ranges_num = ms->numa_state->mem_ranges_num;
>  NumaMemRange *mem_ranges = ms->numa_state->mem_ranges;
> +HMAT_LB_Info *numa_hmat_lb;
>  
>  PCMachineState *pcms = PC_MACHINE(ms);
>  AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_GET_CLASS(pcms->acpi_dev);
> @@ -117,6 +135,83 @@ static void hmat_build_hma(GArray *table_data, 
> MachineState *ms)
>  i = object_property_get_uint(OBJECT(dimm), PC_DIMM_NODE_PROP, NULL);
>  build_hmat_spa(table_data, ms, mem_base, mem_len, i);
>  }
> 

Considering below part is sufficiently big, I'd move it into separate function
ex: build_hmat_lb()

> +if (!num_initiator && !num_target) {
> +classify_proximity_domains(ms);
This part I'd just inline instead of it being a separate function
and make initiator_pxm,target_pxm,num_initiator,num_target local variables
instead of globals. (is there a reason why they weren't made locals?)

> +}
> +
> +/* Build HMAT System Locality Latency and Bandwidth Information. */
> +for (hrchy = HMAT_LB_MEM_MEMORY;
> + hrchy <= HMAT_LB_MEM_CACHE_3RD_LEVEL; hrchy++) {
> +for (type = HMAT_LB_DATA_ACCESS_LATENCY;
> + type <= HMAT_LB_DATA_WRITE_BANDWIDTH; type++) {
> +numa_hmat_lb = ms->numa_state->hmat_lb[hrchy][type];
> +
> +if (numa_hmat_lb) {
> +uint32_t s = num_initiator;
> +uint32_t t = num_target;
> +uint8_t m, n;
> +
> +/* Type */
> +build_append_int_noprefix(table_data, 1, 2);
> +/* Reserved */
> +build_append_int_noprefix(table_data, 0, 2);
> +/* Length */
> +build_append_int_noprefix(table_data,
> +  32 + 4 * s + 4 * t + 2 * s * t, 4);
> +/* Flags */
> +build_append_int_noprefix(table_data,
> +  numa_hmat_lb->hierarchy, 1);
> +/* Data Type */
> +build_append_int_noprefix(table_data,
> +  numa_hmat_lb->data_type, 1);
> +/* Reserved */
> +build_append_int_noprefix(table_data, 0, 2);
> +/* Number of Initiator Proximity Domains (s) */
> +build_append_int_noprefix(table_data, s, 4);
> +/* Number of Target Proximity Domains (t) */
> +build_append_int_noprefix(table_data, t, 4);
> +/* Reserved

Re: [Qemu-devel] [Qemu-ppc] [PATCH v9 1/6] ppc: spapr: Handle "ibm, nmi-register" and "ibm, nmi-interlock" RTAS calls

[Greg Kurz]

On Tue, 4 Jun 2019 11:38:31 +0530
Aravinda Prasad  wrote:

> On Monday 03 June 2019 04:47 PM, Greg Kurz wrote:
> > On Mon, 3 Jun 2019 12:12:43 +0200
> > Greg Kurz  wrote:
> >   
> >> On Wed, 29 May 2019 11:10:14 +0530
> >> Aravinda Prasad  wrote:
> >>  
> >>> This patch adds support in QEMU to handle "ibm,nmi-register"
> >>> and "ibm,nmi-interlock" RTAS calls.
> >>>
> >>> The machine check notification address is saved when the
> >>> OS issues "ibm,nmi-register" RTAS call.
> >>>
> >>> This patch also handles the case when multiple processors
> >>> experience machine check at or about the same time by
> >>> handling "ibm,nmi-interlock" call. In such cases, as per
> >>> PAPR, subsequent processors serialize waiting for the first
> >>> processor to issue the "ibm,nmi-interlock" call. The second
> >>> processor that also received a machine check error waits
> >>> till the first processor is done reading the error log.
> >>> The first processor issues "ibm,nmi-interlock" call
> >>> when the error log is consumed. This patch implements the
> >>> releasing part of the error-log while subsequent patch
> >>> (which builds error log) handles the locking part.
> >>>
> >>> Signed-off-by: Aravinda Prasad 
> >>> Reviewed-by: David Gibson 
> >>> ---
> >>
> >> The code looks okay but it still seems wrong to advertise the RTAS
> >> calls to the guest that early in the series. The linux kernel in
> >> the guest will assume FWNMI is functional, which isn't true until
> >> patch 6 (yes, migration is part of the feature, it should be
> >> supported upfront, not fixed afterwards).
> >>
> >> It doesn't help much to introduce the RTAS calls early and to
> >> modify them in the other patches. I'd rather see the rest of
> >> the code first and a final patch that introduces the fully
> >> functional RTAS calls and calls spapr_rtas_register().
> >>  
> > 
> > Thinking again, you should introduce the "fwnmi-mce" spapr capability in
> > its own patch first, default to "off" and and have the last patch in the
> > series to switch the default to "on" for newer machine types only.
> > 
> > This patch should then only register the RTAS calls if "fwnmi-mcr" is set
> > to "on".
> > 
> > This should address the fact that we don't want to expose a partially
> > implemented FWNMI feature to the guest, and we don't want to support
> > FWNMI at all with older machine types for the sake of compatibility.  
> 
> When you say "expose a partially implemented FWNMI feature to the
> guest", do you mean while debugging/bisect we may end up with exposing
> the partially implemented FWNMI feature? Otherwise it is expected that

Yes, we don't want to break someone else's bisect.

> QEMU runs with all the 6 patches.
> 
> If that is the case, I will have the rtas nmi register functionality as
> the last patch in the series. This way we don't have to have spapr cap
> turned off first and later turned on. However, as mentioned earlier
> (when David raised the same concern), use of guest_machine_check_addr
> may look odd at other patches as it is set only during rtas nmi register.
> 

Why odd ?

> Or else, as a workaround, I can return RTAS_OUT_NOT_SUPPORTED for rtas
> nmi register till the entire functionality is implemented and only in
> the last patch in the series I will return RTAS_OUT_SUCCESS. This will
> ensure that we have a logical connection between the patches and the
> partially implemented fwnmi is not exposed to the guest kernel.
> 

Not exactly true. FWNMI would be exposed to the guest in the device tree
and the guest kernel would _just_ fail to set the fwnmi_active global:

if (0 == rtas_call(ibm_nmi_register, 2, 1, NULL, system_reset_addr,
machine_check_addr))
fwnmi_active = 1;

> Regards,
> Aravinda
> 
> 
> 
> 
> >   
> >>>  hw/ppc/spapr.c |7 +
> >>>  hw/ppc/spapr_rtas.c|   65 
> >>> 
> >>>  include/hw/ppc/spapr.h |9 ++-
> >>>  3 files changed, 80 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> >>> index e2b33e5..fae28a9 100644
> >>> --- a/hw/ppc/spapr.c
> >>> +++ b/hw/ppc/spapr.c
> >>> @@ -1808,6 +1808,11 @@ static void spapr_machine_reset(void)
> >>>  first_ppc_cpu->env.gpr[5] = 0;
> >>>  
> >>>  spapr->cas_reboot = false;
> >>> +
> >>> +spapr->guest_machine_check_addr = -1;
> >>> +
> >>> +/* Signal all vCPUs waiting on this condition */
> >>> +qemu_cond_broadcast(&spapr->mc_delivery_cond);
> >>>  }
> >>>  
> >>>  static void spapr_create_nvram(SpaprMachineState *spapr)
> >>> @@ -3072,6 +3077,8 @@ static void spapr_machine_init(MachineState 
> >>> *machine)
> >>>  
> >>>  kvmppc_spapr_enable_inkernel_multitce();
> >>>  }
> >>> +
> >>> +qemu_cond_init(&spapr->mc_delivery_cond);
> >>>  }
> >>>  
> >>>  static int spapr_kvm_type(MachineState *machine, const char *vm_type)
> >>> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
> >>

Re: [Qemu-devel] [PATCH v8 0/3] linux-user: A set of miscellaneous patches

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/1559653142-31892-1-git-send-email-aleksandar.marko...@rt-rk.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  aarch64_be-linux-user/linux-user/syscall.o
  CC  alpha-linux-user/tcg/tcg-op-gvec.o
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c: In function 
‘do_setsockopt’:
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c:2005:14: error: 
‘ALG_SET_KEY’ undeclared (first use in this function)
 2005 | case ALG_SET_KEY:
  |  ^~~
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c:2005:14: note: 
each undeclared identifier is reported only once for each function it appears in
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c:2021:14: error: 
‘ALG_SET_AEAD_AUTHSIZE’ undeclared (first use in this function)
 2021 | case ALG_SET_AEAD_AUTHSIZE:
  |  ^
make[1]: *** [/var/tmp/patchew-tester-tmp-aqn3loys/src/rules.mak:69: 
linux-user/syscall.o] Error 1
---
  CC  alpha-linux-user/linux-user/main.o
  CC  alpha-linux-user/linux-user/syscall.o
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c: In function 
‘do_setsockopt’:
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c:2005:14: error: 
‘ALG_SET_KEY’ undeclared (first use in this function)
 2005 | case ALG_SET_KEY:
  |  ^~~
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c:2005:14: note: 
each undeclared identifier is reported only once for each function it appears in
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c:2021:14: error: 
‘ALG_SET_AEAD_AUTHSIZE’ undeclared (first use in this function)
 2021 | case ALG_SET_AEAD_AUTHSIZE:
  |  ^
make[1]: *** [/var/tmp/patchew-tester-tmp-aqn3loys/src/rules.mak:69: 
linux-user/syscall.o] Error 1
---
  CC  aarch64-linux-user/linux-user/syscall.o
  CC  aarch64-linux-user/linux-user/strace.o
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c: In function 
‘do_setsockopt’:
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c:2005:14: error: 
‘ALG_SET_KEY’ undeclared (first use in this function)
 2005 | case ALG_SET_KEY:
  |  ^~~
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c:2005:14: note: 
each undeclared identifier is reported only once for each function it appears in
/var/tmp/patchew-tester-tmp-aqn3loys/src/linux-user/syscall.c:2021:14: error: 
‘ALG_SET_AEAD_AUTHSIZE’ undeclared (first use in this function)
 2021 | case ALG_SET_AEAD_AUTHSIZE:
  |  ^
make[1]: *** [/var/tmp/patchew-tester-tmp-aqn3loys/src/rules.mak:69: 
linux-user/syscall.o] Error 1


The full log is available at
http://patchew.org/logs/1559653142-31892-1-git-send-email-aleksandar.marko...@rt-rk.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 v4 07/11] hmat acpi: Build Memory Side Cache Information Structure(s) in ACPI HMAT

[Igor Mammedov]

On Wed,  8 May 2019 14:17:22 +0800
Tao Xu  wrote:

> From: Liu Jingqi 
> 
> This structure describes memory side cache information for memory
> proximity domains if the memory side cache is present and the
> physical device(SMBIOS handle) forms the memory side cache.
> The software could use this information to effectively place
> the data in memory to maximize the performance of the system
> memory that use the memory side cache.
> 
> Signed-off-by: Liu Jingqi 
> Signed-off-by: Tao Xu 
> ---
> 
> Changes in v4 -> v3:
> - use build_append_int_noprefix() to build Memory Side Cache
> Information Structure(s) tables (Igor)
> - move globals (hmat_cache_info) into MachineState (Igor)
> - move hmat_build_cache() inside of hmat_build_hma() (Igor)
> ---
>  hw/acpi/hmat.c  | 50 -
>  hw/acpi/hmat.h  | 25 +
>  include/hw/boards.h |  3 +++
>  include/qemu/typedefs.h |  1 +
>  include/sysemu/sysemu.h |  8 +++
>  5 files changed, 86 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
> index 54aabf77eb..3a8c41162d 100644
> --- a/hw/acpi/hmat.c
> +++ b/hw/acpi/hmat.c
> @@ -102,10 +102,11 @@ static void hmat_build_hma(GArray *table_data, 
> MachineState *ms)
>  {
>  GSList *device_list = NULL;
>  uint64_t mem_base, mem_len;
> -int i, j, hrchy, type;
> +int i, j, hrchy, type, level;
>  uint32_t mem_ranges_num = ms->numa_state->mem_ranges_num;
>  NumaMemRange *mem_ranges = ms->numa_state->mem_ranges;
>  HMAT_LB_Info *numa_hmat_lb;
> +HMAT_Cache_Info *numa_hmat_cache = NULL;
>  
>  PCMachineState *pcms = PC_MACHINE(ms);
>  AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_GET_CLASS(pcms->acpi_dev);
> @@ -212,6 +213,53 @@ static void hmat_build_hma(GArray *table_data, 
> MachineState *ms)
>  }
>  }
>  }
> +
> +/* Build HMAT Memory Side Cache Information. */
> +for (i = 0; i < ms->numa_state->num_nodes; i++) {
> +for (level = 0; level <= MAX_HMAT_CACHE_LEVEL; level++) {
> +numa_hmat_cache = ms->numa_state->hmat_cache[i][level];
> +if (numa_hmat_cache) {
> +uint16_t n = numa_hmat_cache->num_smbios_handles;


> +uint32_t cache_attr = HMAT_CACHE_TOTAL_LEVEL(
> +  numa_hmat_cache->total_levels);
> +cache_attr |= HMAT_CACHE_CURRENT_LEVEL(
> +  numa_hmat_cache->level);
> +cache_attr |= HMAT_CACHE_ASSOC(
> +  numa_hmat_cache->associativity);
> +cache_attr |= HMAT_CACHE_WRITE_POLICY(
> +  numa_hmat_cache->write_policy);
> +cache_attr |= HMAT_CACHE_LINE_SIZE(
> +  numa_hmat_cache->line_size);
I don't see a merit of hiding bitfield manipulation behind macro
I'd suggest to drop macros here and mask+shift data here.

> +cache_attr = cpu_to_le32(cache_attr);
> +
> +/* Memory Side Cache Information Structure */
> +/* Type */
> +build_append_int_noprefix(table_data, 2, 2);
> +/* Reserved */
> +build_append_int_noprefix(table_data, 0, 2);
> +/* Length */
> +build_append_int_noprefix(table_data, 32 + 2 * n, 4);
> +/* Proximity Domain for the Memory */
> +build_append_int_noprefix(table_data,
> +  numa_hmat_cache->mem_proximity, 4);
> +/* Reserved */
> +build_append_int_noprefix(table_data, 0, 4);
> +/* Memory Side Cache Size */
> +build_append_int_noprefix(table_data,
> +  numa_hmat_cache->size, 8);
> +/* Cache Attributes */
> +build_append_int_noprefix(table_data, cache_attr, 4);
> +/* Reserved */
> +build_append_int_noprefix(table_data, 0, 2);
> +/* Number of SMBIOS handles (n) */
> +build_append_int_noprefix(table_data, n, 2);
> +
> +/* SMBIOS Handles */
> +/* TBD: set smbios handles */
> +build_append_int_noprefix(table_data, 0, 2 * n);
Is memory side cache structure useful at all without pointing to SMBIOS entries?

> +}
> +}
> +}
>  }
>  
>  void hmat_build_acpi(GArray *table_data, BIOSLinker *linker, MachineState 
> *ms)
> diff --git a/hw/acpi/hmat.h b/hw/acpi/hmat.h
> index f37e30e533..8f563f19dd 100644
> --- a/hw/acpi/hmat.h
> +++ b/hw/acpi/hmat.h
> @@ -77,6 +77,31 @@ struct HMAT_LB_Info {
>  uint16_tbandwidth[MAX_NODES][MAX_NODES];
>  };
>  
> +struct HMAT_Cache_Info {
> +/* The memory proximity domain to which the memory belongs. */
> +uint32_tmem_proximity

Re: [Qemu-devel] qgraph

[Paolo Bonzini]

On 04/06/19 10:37, Natalia Fursova wrote:
> Hello, Paolo!
> 
> We develop GUI for Qemu and want to implement graphical interface for
> configuring the device tree. To do this we need to detect list of the
> devices supported by any specific platform.
> 
> Then we use this tree for command line generation.
> 
> Existing qmp commands don't supply enough information to build the tree.
> They miss bus and interface data.

Hi!

Bus data is implicit in the parent class provided by QMP.  For example,
pci-device is the superclass of PCI devices, scsi-device is the
superclass of SCSI devices, etc.

qgraph is indeed similar, but it is only used by test cases, not by QEMU
itself.  The difference is that qgraph links together _drivers_ for the
devices, and so it is limited to those devices that have tests.  For
some ideas behind qgraph, see
https://wiki.qemu.org/Features/qtest_driver_framework.

Paolo

> 
>  
> 
> There is something called 'qgraph' in Qemu. It looks similar to data
> structures in our GUI tool.
> 
>  
> 
> Tell me please, do you have a plan on improving this interface? We found the
> following hardcoded lines in the tests:
> 
> qos_node_consumes("megasas", "pci-bus", &opts);
> 
> qos_node_produces("megasas", "pci-device");
> 
>  
> 
> And we wanted to extend QMP to query this kind of information.
> 
>  
> 
>  
> 
> Best regards, 
> 
> Natalia
> 
>  
> 

[Qemu-devel] [PATCH 2/2] vl: Document why objects are delayed

[Markus Armbruster]

Objects should not be "delayed" without a reason, as the previous
commit demonstrates.  The remaining ones have reasons.  State them.
and demand future ones come with such a statement.

Signed-off-by: Markus Armbruster 
---
 vl.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index cc6246d2af..cd1fbc4cdc 100644
--- a/vl.c
+++ b/vl.c
@@ -2751,19 +2751,25 @@ static bool object_create_initial(const char *type, 
QemuOpts *opts)
 exit(0);
 }
 
+/*
+ * Objects should not be made "delayed" without a reason.  If you
+ * add one, state the reason in a comment!
+ */
+
+/* Reason: rng-egd property "chardev" */
 if (g_str_equal(type, "rng-egd")) {
 return false;
 }
 
 #if defined(CONFIG_VHOST_USER) && defined(CONFIG_LINUX)
+/* Reason: cryptodev-vhost-user property "chardev" */
 if (g_str_equal(type, "cryptodev-vhost-user")) {
 return false;
 }
 #endif
 
 /*
- * return false for concrete netfilters since
- * they depend on netdevs already existing
+ * Reason: filter-* property "netdev" etc.
  */
 if (g_str_equal(type, "filter-buffer") ||
 g_str_equal(type, "filter-dump") ||
-- 
2.21.0

[Qemu-devel] [PATCH 0/2] vl: Fix -drive / -blockdev persistent reservation management

[Markus Armbruster]

This is a minimal regression fix.  There's more work to do nearby.
Left for another day.

Markus Armbruster (2):
  vl: Fix -drive / -blockdev persistent reservation management
  vl: Document why objects are delayed

 vl.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

-- 
2.21.0

[Qemu-devel] [PATCH 1/2] vl: Fix -drive / -blockdev persistent reservation management

[Markus Armbruster]

qemu-system-FOO's main() acts on command line arguments in its own
idiosyncratic order.  There's not much method to its madness.
Whenever we find a case where one kind of command line argument needs
to refer to something created for another kind later, we rejigger the
order.

Recent commit cda4aa9a5a "vl: Create block backends before setting
machine properties" was such a rejigger.  Block backends are now
created before "delayed" objects.  This broke persistent reservation
management.  Reproducer:

$ qemu-system-x86_64 -object 
pr-manager-helper,id=pr-helper0,path=/tmp/pr-helper0.sock-drive -drive 
file=/dev/mapper/crypt,file.pr-manager=pr-helper0,format=raw,if=none,id=drive-scsi0-0-0-2
qemu-system-x86_64: -drive 
file=/dev/mapper/crypt,file.pr-manager=pr-helper0,format=raw,if=none,id=drive-scsi0-0-0-2:
 No persistent reservation manager with id 'pr-helper0'

The delayed pr-manager-helper object is created too late for use by
-drive or -blockdev.  Normal objects are still created in time.

pr-manager-helper has always been a delayed object (commit 7c9e527659
"scsi, file-posix: add support for persistent reservation
management").  Turns out there's no real reason for that.  Make it a
normal object.

Fixes: cda4aa9a5a08777cf13e164c0543bd4888b8adce
Signed-off-by: Markus Armbruster 
---
 vl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index f023a8ca73..cc6246d2af 100644
--- a/vl.c
+++ b/vl.c
@@ -2751,8 +2751,7 @@ static bool object_create_initial(const char *type, 
QemuOpts *opts)
 exit(0);
 }
 
-if (g_str_equal(type, "rng-egd") ||
-g_str_has_prefix(type, "pr-manager-")) {
+if (g_str_equal(type, "rng-egd")) {
 return false;
 }
 
-- 
2.21.0

Re: [Qemu-devel] [PATCH 0/2] vl: Fix -drive / -blockdev persistent reservation management

[Michal Privoznik]

On 6/4/19 5:12 PM, Markus Armbruster wrote:

This is a minimal regression fix.  There's more work to do nearby.
Left for another day.

Markus Armbruster (2):
   vl: Fix -drive / -blockdev persistent reservation management
   vl: Document why objects are delayed

  vl.c | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)



Reviewed-by: Michal Privoznik 

Thanks for fixing this.

Michal

[Qemu-devel] [PATCH] decodetree: Fix comparison of Field

[Richard Henderson]

Typo comparing the sign of the field, twice, instead of also comparing
the mask of the field (which itself encodes both position and length).

Reported-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 scripts/decodetree.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/decodetree.py b/scripts/decodetree.py
index 81874e22cc..d7a59d63ac 100755
--- a/scripts/decodetree.py
+++ b/scripts/decodetree.py
@@ -184,7 +184,7 @@ class Field:
 return '{0}(insn, {1}, {2})'.format(extr, self.pos, self.len)
 
 def __eq__(self, other):
-return self.sign == other.sign and self.sign == other.sign
+return self.sign == other.sign and self.mask == other.mask
 
 def __ne__(self, other):
 return not self.__eq__(other)
-- 
2.17.1

Re: [Qemu-devel] Deprecation policy and build dependencies

[John Snow]

On 6/4/19 1:31 AM, Markus Armbruster wrote:
> Peter Maydell  writes:
> 
>> On Mon, 3 Jun 2019 at 19:21, John Snow  wrote:
>>> I get it, we don't want to require Python 3.8 because some dev wanted
>>> assignment conditionals -- but we're talking about Python 2 here, which
>>> suffers its EOL by the end of this calendar year.
> 
> "Not because some dev wanted assignment conditionals" is the non-reason.
> Let me spell out the reason: supporting Python 2 is expensive for us.
> As the amount of Python code grows, it gets more and more expensive.
> 
> Is this really time and effort well spent?
> 

I'd just like to clarify that you and I are arguing the same point. I
used that non-reason intentionally, arguing that we don't want a trivial
feature, we're talking about the major deprecation of an entire version
of a language.

I picked a far-fetched, very bleeding edge version (and a feature in it
that matched, sorry, been doing a lot of Python lately) to counter
Peter's point that we didn't want to support bleeding-edge stuff "just
because."

Sorry if I didn't articulate this point well.

>>> So do we think it's reasonable to drop support for Python2 for the
>>> release that comes out after Python2's EOL, or do we insist on 2x3
>>> simultaneous support for years more?
>>
>> I don't have a strong opinion on Python in particular, but
>> I think it would be nicer to avoid the "python is a special
>> snowflake" effect.
> 
> Lots of things are nice.  Limited resources dictate we can only get some
> of them.
> 
>>Would it really be so bad for it to just
>> be "drop it when it falls off the last LTS distro" like the
>> rest of our dependencies ?
> 
> In my experience maintaining and evolving the QAPI generators,
> supporting both Python 2 and 3 is a constant distraction that adds up
> over time.  It's all manual; we decided against adopting one of tool
> chains made for dealing with this mess.  I'd rather think about how to
> solve real user problems like deprecation information or command line
> introspection than deal with Python 2 vs. 3 arcana.
> 
> Just the other day, I flagged an innocent-looking simplification of some
> non-QAPI Python code that changed semantics subtly on Python 2, impact
> unknown.  The developer did not know.  The fact that I waste precious
> brain capacity on knowing this shit (pardon my French) is a bloody
> shame.  Well, some of this shit, because I've screwed it up myself, too.
> 
> The sooner we stop the bleeding, the better.
> 

I agree, and it looks like we have consensus that because RHEL7 has
EPEL, we can drop Python 2 support. I think.

What wasn't made clear to me yet is in which version we may do so. I
think I suggested 4.2, and nobody agreed or disagreed with that point.

--js

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

[Peter Maydell]

On Mon, 3 Jun 2019 at 19:08, Michael S. Tsirkin  wrote:
>
> The following changes since commit 8c1ecb590497b0349c550607db923972b37f6963:
>
>   Merge remote-tracking branch 
> 'remotes/stsquad/tags/pull-testing-next-280519-2' into staging (2019-05-28 
> 17:38:32 +0100)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>
> for you to fetch changes up to df7cafdeb68b6572fa81d2be9a1910547c4dfafc:
>
>   bios-tables-test: list all tables that differ (2019-06-03 08:05:43 -0400)
>
> 
> virtio, pci, pc: cleanups, features
>
> stricter rules for acpi tables: we now fail
> on any difference that isn't whitelisted.
>
> vhost-scsi migration.
>
> some cleanups all over the place
>
> Signed-off-by: Michael S. Tsirkin 
>
> 


Hi; I'm afraid this fails 'make check' on my aarch32 build:

MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
QTEST_QEMU_BINARY=i386-softmmu/qemu-system-i386
QTEST_QEMU_IMG=qemu-img tests/bios-tables-test -m=quick -k --tap <
/dev/null | ./scripts/tap-driver.pl --test-name="bios-tables-test"

Looking for expected file 'tests/data/acpi/pc/FACP'
Using expected file 'tests/data/acpi/pc/FACP'
Looking for expected file 'tests/data/acpi/pc/APIC'
Using expected file 'tests/data/acpi/pc/APIC'
Looking for expected file 'tests/data/acpi/pc/HPET'
Using expected file 'tests/data/acpi/pc/HPET'
Looking for expected file 'tests/data/acpi/pc/FACS'
Using expected file 'tests/data/acpi/pc/FACS'
Looking for expected file 'tests/data/acpi/pc/DSDT'
Using expected file 'tests/data/acpi/pc/DSDT'
PASS 1 bios-tables-test /i386/acpi/piix4

Looking for expected file 'tests/data/acpi/q35/FACP'
Using expected file 'tests/data/acpi/q35/FACP'
Looking for expected file 'tests/data/acpi/q35/APIC'
Using expected file 'tests/data/acpi/q35/APIC'
Looking for expected file 'tests/data/acpi/q35/HPET'
Using expected file 'tests/data/acpi/q35/HPET'
Looking for expected file 'tests/data/acpi/q35/MCFG'
Using expected file 'tests/data/acpi/q35/MCFG'
Looking for expected file 'tests/data/acpi/q35/FACS'
Using expected file 'tests/data/acpi/q35/FACS'
Looking for expected file 'tests/data/acpi/q35/DSDT'
Using expected file 'tests/data/acpi/q35/DSDT'
acpi-test: Warning! DSDT mismatch. Actual [asl:/tmp/asl-NKUU2Z.dsl,
aml:/tmp/aml-UERV2Z], Expected [asl:/tmp/asl-3ITW2Z.dsl,
aml:tests/data/acpi/q35/DSDT].
acpi-test: Warning. not showing difference since no diff utility is
specified. Set 'DIFF' environment variable to a preferred diff utility
and run 'make V=1 check' again to see ASL difference.**
ERROR:/home/peter.maydell/qemu/tests/bios-tables-test.c:422:test_acpi_asl:
assertion failed: (all_tables_match)
Aborted
ERROR - too few tests run (expected 15, got 1)
/home/peter.maydell/qemu/tests/Makefile.include:884: recipe for target
'check-qtest-i386' failed


This is the only 32-bit host I test on, so it may be a generic
32-bit host problem rather than arm-specific.

thanks
-- PMM

Re: [Qemu-devel] QEMU tries to register to VFIO memory that is not RAM

[Thanos Makatos]

> > Indeed. Could we decide whether or not to register an address space with
> > VFIO in a more intelligent manner? E.g. the following simplistic patch 
> > solves
> > our problem:
> >
> > diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> > index 4374cc6176..d9d3b1277a 100644
> > --- a/hw/vfio/common.c
> > +++ b/hw/vfio/common.c
> > @@ -430,6 +430,9 @@ static void
> vfio_listener_region_add(MemoryListener *listener,
> >  VFIOHostDMAWindow *hostwin;
> >  bool hostwin_found;
> >
> > +if (!section->mr->ram_device)
> > +return;
> > +
> 
> Nope, this would prevent IOMMU mapping of assigned device MMIO
> regions
> which would prevent peer-to-peer DMA between assigned devices.  Thanks,

Understood.

Is there a strong reason why QEMU allocates memory for these address spaces 
without MAP_SHARED? In our use case it would solve our problem if we could make 
QEMU use MAP_SHARED. I understand that this isn't strictly correct, so would it 
be acceptable to enable this behavior with a command-line option or an #ifdef?

Re: [Qemu-devel] [PATCH] decodetree: Fix comparison of Field

[Peter Maydell]

On Tue, 4 Jun 2019 at 16:42, Richard Henderson
 wrote:
>
> Typo comparing the sign of the field, twice, instead of also comparing
> the mask of the field (which itself encodes both position and length).
>
> Reported-by: Peter Maydell 
> Signed-off-by: Richard Henderson 
> ---
>  scripts/decodetree.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/decodetree.py b/scripts/decodetree.py
> index 81874e22cc..d7a59d63ac 100755
> --- a/scripts/decodetree.py
> +++ b/scripts/decodetree.py
> @@ -184,7 +184,7 @@ class Field:
>  return '{0}(insn, {1}, {2})'.format(extr, self.pos, self.len)
>
>  def __eq__(self, other):
> -return self.sign == other.sign and self.sign == other.sign
> +return self.sign == other.sign and self.mask == other.mask
>
>  def __ne__(self, other):
>  return not self.__eq__(other)
> --

Reviewed-by: Peter Maydell 

This fixes the problems I was seeing with the VFP decodetree
conversion I was working on.

thanks
-- PMM

[Qemu-devel] [PULL v2 00/29] Block layer patches

[Kevin Wolf]

The following changes since commit e2a58ff493a2e00db3e963c1839c5374500110f2:

  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging 
(2019-06-03 18:26:21 +0100)

are available in the Git repository at:

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

for you to fetch changes up to 11ba81c3cde0bc070cced6e8ef2835fab4fe90c8:

  iotests: Fix duplicated diff output on failure (2019-06-04 16:55:58 +0200)


Block layer patches:

- block: AioContext management, part 2
- Avoid recursive block_status call (i.e. lseek() calls) if possible
- linux-aio: Drop unused BlockAIOCB submission method
- nvme: add Get/Set Feature Timestamp support
- Fix crash on commit job start with active I/O on base node
- Fix crash in bdrv_drained_end
- Fix integer overflow in qcow2 discard


John Snow (1):
  blockdev: fix missed target unref for drive-backup

Julia Suvorova (1):
  block/linux-aio: Drop unused BlockAIOCB submission method

Kenneth Heitke (1):
  nvme: add Get/Set Feature Timestamp support

Kevin Wolf (19):
  block: Drain source node in bdrv_replace_node()
  iotests: Test commit job start with concurrent I/O
  test-block-iothread: Check filter node in test_propagate_mirror
  nbd-server: Call blk_set_allow_aio_context_change()
  block: Add Error to blk_set_aio_context()
  block: Add BlockBackend.ctx
  block: Add qdev_prop_drive_iothread property type
  scsi-disk: Use qdev_prop_drive_iothread
  block: Adjust AioContexts when attaching nodes
  test-block-iothread: Test adding parent to iothread node
  test-block-iothread: BlockBackend AioContext across root node change
  block: Move node without parents to main AioContext
  blockdev: Use bdrv_try_set_aio_context() for monitor commands
  block: Remove wrong bdrv_set_aio_context() calls
  virtio-scsi-test: Test attaching new overlay with iothreads
  iotests: Attach new devices to node in non-default iothread
  test-bdrv-drain: Use bdrv_try_set_aio_context()
  block: Remove bdrv_set_aio_context()
  iotests: Fix duplicated diff output on failure

Max Reitz (2):
  block/io: Delay decrementing the quiesce_counter
  iotests: Test cancelling a job and closing the VM

Vladimir Sementsov-Ogievskiy (5):
  tests/perf: Test lseek influence on qcow2 block-status
  block: avoid recursive block_status call if possible
  block/qcow2-refcount: add trace-point to qcow2_process_discards
  block/io: bdrv_pdiscard: support int64_t bytes parameter
  iotests: test big qcow2 shrink

 docs/devel/multiple-iothreads.txt  |   4 +-
 block/qcow2.h  |   4 +
 hw/block/nvme.h|   2 +
 include/block/block.h  |  21 ++---
 include/block/block_int.h  |   1 +
 include/block/nvme.h   |   2 +
 include/block/raw-aio.h|   3 -
 include/hw/block/block.h   |   7 +-
 include/hw/qdev-properties.h   |   3 +
 include/hw/scsi/scsi.h |   1 +
 include/sysemu/block-backend.h |   5 +-
 tests/libqtest.h   |  11 +++
 block.c|  79 -
 block/backup.c |   3 +-
 block/block-backend.c  |  47 ++
 block/commit.c |  13 +--
 block/crypto.c |   3 +-
 block/io.c |  28 +++---
 block/linux-aio.c  |  72 +++
 block/mirror.c |   4 +-
 block/parallels.c  |   3 +-
 block/qcow.c   |   3 +-
 block/qcow2-refcount.c |  39 -
 block/qcow2.c  |  17 +++-
 block/qed.c|   3 +-
 block/sheepdog.c   |   3 +-
 block/vdi.c|   3 +-
 block/vhdx.c   |   3 +-
 block/vmdk.c   |   3 +-
 block/vpc.c|   3 +-
 blockdev.c |  61 +++--
 blockjob.c |  12 ++-
 hmp.c  |   3 +-
 hw/block/dataplane/virtio-blk.c|  12 ++-
 hw/block/dataplane/xen-block.c |   6 +-
 hw/block/fdc.c |   2 +-
 hw/block/nvme.c| 106 +-
 hw/block/xen-block.c   |   2 +-
 hw/core/qdev-properties-system.c   |  41 -
 hw/ide/qdev.c  |   2 +-
 hw/scsi/scsi-disk.c|  24 +++--
 hw/scsi/virtio-scsi.c  

[Qemu-devel] [PATCH v2 12/12] block/qcow2: implement .bdrv_co_pwritev(_compressed)_part

[Vladimir Sementsov-Ogievskiy]

Implement and use new interface to get rid of hd_qiov.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/qcow2.h |  1 +
 include/qemu/iov.h|  1 +
 block/qcow2-cluster.c |  9 ---
 block/qcow2.c | 60 +--
 util/iov.c| 10 
 5 files changed, 48 insertions(+), 33 deletions(-)

diff --git a/block/qcow2.h b/block/qcow2.h
index 567375e56c..ea3bdb0699 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -417,6 +417,7 @@ typedef struct QCowL2Meta
  * from @cow_start and @cow_end into one single write operation.
  */
 QEMUIOVector *data_qiov;
+size_t data_qiov_offset;
 
 /** Pointer to next L2Meta of the same write request */
 struct QCowL2Meta *next;
diff --git a/include/qemu/iov.h b/include/qemu/iov.h
index 29957c8a72..bffc151282 100644
--- a/include/qemu/iov.h
+++ b/include/qemu/iov.h
@@ -206,6 +206,7 @@ void qemu_iovec_init_extended(
 void *tail_buf, size_t tail_len);
 void qemu_iovec_init_slice(QEMUIOVector *qiov, QEMUIOVector *source,
size_t offset, size_t len);
+int qemu_iovec_subvec_niov(QEMUIOVector *qiov, size_t offset, size_t len);
 void qemu_iovec_add(QEMUIOVector *qiov, void *base, size_t len);
 void qemu_iovec_concat(QEMUIOVector *dst,
QEMUIOVector *src, size_t soffset, size_t sbytes);
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 1159d6ed2f..00b1a9ab8d 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -830,7 +830,6 @@ static int perform_cow(BlockDriverState *bs, QCowL2Meta *m)
 assert(start->nb_bytes <= UINT_MAX - end->nb_bytes);
 assert(start->nb_bytes + end->nb_bytes <= UINT_MAX - data_bytes);
 assert(start->offset + start->nb_bytes <= end->offset);
-assert(!m->data_qiov || m->data_qiov->size == data_bytes);
 
 if ((start->nb_bytes == 0 && end->nb_bytes == 0) || m->skip_cow) {
 return 0;
@@ -862,7 +861,11 @@ static int perform_cow(BlockDriverState *bs, QCowL2Meta *m)
 /* The part of the buffer where the end region is located */
 end_buffer = start_buffer + buffer_size - end->nb_bytes;
 
-qemu_iovec_init(&qiov, 2 + (m->data_qiov ? m->data_qiov->niov : 0));
+qemu_iovec_init(&qiov, 2 + (m->data_qiov ?
+qemu_iovec_subvec_niov(m->data_qiov,
+   m->data_qiov_offset,
+   data_bytes)
+: 0));
 
 qemu_co_mutex_unlock(&s->lock);
 /* First we read the existing data from both COW regions. We
@@ -905,7 +908,7 @@ static int perform_cow(BlockDriverState *bs, QCowL2Meta *m)
 if (start->nb_bytes) {
 qemu_iovec_add(&qiov, start_buffer, start->nb_bytes);
 }
-qemu_iovec_concat(&qiov, m->data_qiov, 0, data_bytes);
+qemu_iovec_concat(&qiov, m->data_qiov, m->data_qiov_offset, 
data_bytes);
 if (end->nb_bytes) {
 qemu_iovec_add(&qiov, end_buffer, end->nb_bytes);
 }
diff --git a/block/qcow2.c b/block/qcow2.c
index c389ef07b0..850117cfa2 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -2091,7 +2091,8 @@ fail:
 /* Check if it's possible to merge a write request with the writing of
  * the data from the COW regions */
 static bool merge_cow(uint64_t offset, unsigned bytes,
-  QEMUIOVector *hd_qiov, QCowL2Meta *l2meta)
+  QEMUIOVector *qiov, size_t qiov_offset,
+  QCowL2Meta *l2meta)
 {
 QCowL2Meta *m;
 
@@ -2120,11 +2121,12 @@ static bool merge_cow(uint64_t offset, unsigned bytes,
 
 /* Make sure that adding both COW regions to the QEMUIOVector
  * does not exceed IOV_MAX */
-if (hd_qiov->niov > IOV_MAX - 2) {
+if (qemu_iovec_subvec_niov(qiov, qiov_offset, bytes) > IOV_MAX - 2) {
 continue;
 }
 
-m->data_qiov = hd_qiov;
+m->data_qiov = qiov;
+m->data_qiov_offset = qiov_offset;
 return true;
 }
 
@@ -2205,24 +2207,22 @@ static int handle_alloc_space(BlockDriverState *bs, 
QCowL2Meta *l2meta)
 return 0;
 }
 
-static coroutine_fn int qcow2_co_pwritev(BlockDriverState *bs, uint64_t offset,
- uint64_t bytes, QEMUIOVector *qiov,
- int flags)
+static coroutine_fn int qcow2_co_pwritev_part(
+BlockDriverState *bs, uint64_t offset, uint64_t bytes,
+QEMUIOVector *qiov, size_t qiov_offset, int flags)
 {
 BDRVQcow2State *s = bs->opaque;
 int offset_in_cluster;
 int ret;
 unsigned int cur_bytes; /* number of sectors in current iteration */
 uint64_t cluster_offset;
-QEMUIOVector hd_qiov;
+QEMUIOVector encrypted_qiov;
 uint64_t bytes_done = 0;
 uint8_t *cluster_data = NULL;
 QCowL2Meta *l2meta = NULL;
 
 trace_qcow2_writev_start_req(qemu_coroutine_self(), offset,

[Qemu-devel] [PATCH v2 08/12] block/io: bdrv_aligned_pwritev: use and support qiov_offset

[Vladimir Sementsov-Ogievskiy]

Use and support new API in bdrv_aligned_pwritev.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/io.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/block/io.c b/block/io.c
index 0cc80e2d5a..660c96527d 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1792,7 +1792,7 @@ bdrv_co_write_req_finish(BdrvChild *child, int64_t 
offset, uint64_t bytes,
  */
 static int coroutine_fn bdrv_aligned_pwritev(BdrvChild *child,
 BdrvTrackedRequest *req, int64_t offset, unsigned int bytes,
-int64_t align, QEMUIOVector *qiov, int flags)
+int64_t align, QEMUIOVector *qiov, size_t qiov_offset, int flags)
 {
 BlockDriverState *bs = child->bs;
 BlockDriver *drv = bs->drv;
@@ -1812,7 +1812,7 @@ static int coroutine_fn bdrv_aligned_pwritev(BdrvChild 
*child,
 assert(is_power_of_2(align));
 assert((offset & (align - 1)) == 0);
 assert((bytes & (align - 1)) == 0);
-assert(!qiov || bytes == qiov->size);
+assert(!qiov || qiov_offset + bytes <= qiov->size);
 max_transfer = QEMU_ALIGN_DOWN(MIN_NON_ZERO(bs->bl.max_transfer, INT_MAX),
align);
 
@@ -1820,7 +1820,7 @@ static int coroutine_fn bdrv_aligned_pwritev(BdrvChild 
*child,
 
 if (!ret && bs->detect_zeroes != BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF &&
 !(flags & BDRV_REQ_ZERO_WRITE) && drv->bdrv_co_pwrite_zeroes &&
-qemu_iovec_is_zero(qiov, 0, qiov->size)) {
+qemu_iovec_is_zero(qiov, qiov_offset, bytes)) {
 flags |= BDRV_REQ_ZERO_WRITE;
 if (bs->detect_zeroes == BLOCKDEV_DETECT_ZEROES_OPTIONS_UNMAP) {
 flags |= BDRV_REQ_MAY_UNMAP;
@@ -1833,15 +1833,15 @@ static int coroutine_fn bdrv_aligned_pwritev(BdrvChild 
*child,
 bdrv_debug_event(bs, BLKDBG_PWRITEV_ZERO);
 ret = bdrv_co_do_pwrite_zeroes(bs, offset, bytes, flags);
 } else if (flags & BDRV_REQ_WRITE_COMPRESSED) {
-ret = bdrv_driver_pwritev_compressed(bs, offset, bytes, qiov, 0);
+ret = bdrv_driver_pwritev_compressed(bs, offset, bytes,
+ qiov, qiov_offset);
 } else if (bytes <= max_transfer) {
 bdrv_debug_event(bs, BLKDBG_PWRITEV);
-ret = bdrv_driver_pwritev(bs, offset, bytes, qiov, 0, flags);
+ret = bdrv_driver_pwritev(bs, offset, bytes, qiov, qiov_offset, flags);
 } else {
 bdrv_debug_event(bs, BLKDBG_PWRITEV);
 while (bytes_remaining) {
 int num = MIN(bytes_remaining, max_transfer);
-QEMUIOVector local_qiov;
 int local_flags = flags;
 
 assert(num);
@@ -1851,12 +1851,10 @@ static int coroutine_fn bdrv_aligned_pwritev(BdrvChild 
*child,
  * need to flush on the last iteration */
 local_flags &= ~BDRV_REQ_FUA;
 }
-qemu_iovec_init(&local_qiov, qiov->niov);
-qemu_iovec_concat(&local_qiov, qiov, bytes - bytes_remaining, num);
 
 ret = bdrv_driver_pwritev(bs, offset + bytes - bytes_remaining,
-  num, &local_qiov, 0, local_flags);
-qemu_iovec_destroy(&local_qiov);
+  num, qiov, bytes - bytes_remaining,
+  local_flags);
 if (ret < 0) {
 break;
 }
@@ -1899,7 +1897,7 @@ static int coroutine_fn bdrv_co_do_zero_pwritev(BdrvChild 
*child,
 
 qemu_iovec_init_buf(&local_qiov, pad.buf, write_bytes);
 ret = bdrv_aligned_pwritev(child, req, aligned_offset, write_bytes,
-   align, &local_qiov,
+   align, &local_qiov, 0,
flags & ~BDRV_REQ_ZERO_WRITE);
 if (ret < 0 || pad.merge_reads) {
 /* Error or all work is done */
@@ -1915,7 +1913,7 @@ static int coroutine_fn bdrv_co_do_zero_pwritev(BdrvChild 
*child,
 /* Write the aligned part in the middle. */
 uint64_t aligned_bytes = bytes & ~(align - 1);
 ret = bdrv_aligned_pwritev(child, req, offset, aligned_bytes, align,
-   NULL, flags);
+   NULL, 0, flags);
 if (ret < 0) {
 goto out;
 }
@@ -1929,7 +1927,8 @@ static int coroutine_fn bdrv_co_do_zero_pwritev(BdrvChild 
*child,
 
 qemu_iovec_init_buf(&local_qiov, pad.tail_buf, align);
 ret = bdrv_aligned_pwritev(child, req, offset, align, align,
-   &local_qiov, flags & ~BDRV_REQ_ZERO_WRITE);
+   &local_qiov, 0,
+   flags & ~BDRV_REQ_ZERO_WRITE);
 }
 
 out:
@@ -1982,7 +1981,7 @@ int coroutine_fn bdrv_co_pwritev(BdrvChild *child,
 }
 
 ret = bdrv_aligned_pwritev(child, &req, offset, bytes, align,
-   qiov, flags);
+

[Qemu-devel] [PATCH v2 01/12] util/iov: introduce qemu_iovec_init_extended

[Vladimir Sementsov-Ogievskiy]

Introduce new initialization API, to create requests with padding. Will
be used in the following patch. New API uses qemu_iovec_init_buf if
resulting io vector has only one element, to avoid extra allocations.
So, we need to update qemu_iovec_destroy to support destroying such
QIOVs.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/qemu/iov.h |   7 +++
 util/iov.c | 112 +++--
 2 files changed, 114 insertions(+), 5 deletions(-)

diff --git a/include/qemu/iov.h b/include/qemu/iov.h
index 48b45987b7..f3787a0cf7 100644
--- a/include/qemu/iov.h
+++ b/include/qemu/iov.h
@@ -199,6 +199,13 @@ static inline void *qemu_iovec_buf(QEMUIOVector *qiov)
 
 void qemu_iovec_init(QEMUIOVector *qiov, int alloc_hint);
 void qemu_iovec_init_external(QEMUIOVector *qiov, struct iovec *iov, int niov);
+void qemu_iovec_init_extended(
+QEMUIOVector *qiov,
+void *head_buf, size_t head_len,
+QEMUIOVector *mid_qiov, size_t mid_offset, size_t mid_len,
+void *tail_buf, size_t tail_len);
+void qemu_iovec_init_slice(QEMUIOVector *qiov, QEMUIOVector *source,
+   size_t offset, size_t len);
 void qemu_iovec_add(QEMUIOVector *qiov, void *base, size_t len);
 void qemu_iovec_concat(QEMUIOVector *dst,
QEMUIOVector *src, size_t soffset, size_t sbytes);
diff --git a/util/iov.c b/util/iov.c
index 74e6ca8ed7..39b6e31494 100644
--- a/util/iov.c
+++ b/util/iov.c
@@ -353,6 +353,103 @@ void qemu_iovec_concat(QEMUIOVector *dst,
 qemu_iovec_concat_iov(dst, src->iov, src->niov, soffset, sbytes);
 }
 
+/*
+ * qiov_find_iov
+ *
+ * Return pointer to iovec structure, where byte at @offset in original vector
+ * @iov exactly is.
+ * Set @remaining_offset to be offset inside that iovec to the same byte.
+ */
+static struct iovec *iov_skip_offset(struct iovec *iov, size_t offset,
+ size_t *remaining_offset)
+{
+while (offset > 0 && offset >= iov->iov_len) {
+offset -= iov->iov_len;
+iov++;
+}
+*remaining_offset = offset;
+
+return iov;
+}
+
+/*
+ * qiov_slice
+ *
+ * Find subarray of iovec's, containing requested range. @head would
+ * be offset in first iov (returned by the function), @tail would be
+ * count of extra bytes in last iovec (returned iov + @niov - 1).
+ */
+static struct iovec *qiov_slice(QEMUIOVector *qiov,
+size_t offset, size_t len,
+size_t *head, size_t *tail, int *niov)
+{
+struct iovec *iov, *end_iov;
+
+assert(offset + len <= qiov->size);
+
+iov = iov_skip_offset(qiov->iov, offset, head);
+end_iov = iov_skip_offset(iov, *head + len, tail);
+
+if (*tail > 0) {
+assert(*tail < end_iov->iov_len);
+*tail = end_iov->iov_len - *tail;
+end_iov++;
+}
+
+*niov = end_iov - iov;
+
+return iov;
+}
+
+/*
+ * Compile new iovec, combining @head_buf buffer, sub-qiov of @mid_qiov,
+ * and @tail_buf buffer into new qiov.
+ */
+void qemu_iovec_init_extended(
+QEMUIOVector *qiov,
+void *head_buf, size_t head_len,
+QEMUIOVector *mid_qiov, size_t mid_offset, size_t mid_len,
+void *tail_buf, size_t tail_len)
+{
+size_t mid_head, mid_tail;
+int total_niov, mid_niov;
+struct iovec *p, *mid_iov;
+
+if (mid_len) {
+mid_iov = qiov_slice(mid_qiov, mid_offset, mid_len,
+ &mid_head, &mid_tail, &mid_niov);
+}
+
+total_niov = !!head_len + mid_niov + !!tail_len;
+if (total_niov == 1) {
+qemu_iovec_init_buf(qiov, NULL, 0);
+p = &qiov->local_iov;
+} else {
+qiov->niov = qiov->nalloc = total_niov;
+qiov->size = head_len + mid_len + tail_len;
+p = qiov->iov = g_new(struct iovec, qiov->niov);
+}
+
+if (head_len) {
+p->iov_base = head_buf;
+p->iov_len = head_len;
+p++;
+}
+
+if (mid_len) {
+memcpy(p, mid_iov, mid_niov * sizeof(*p));
+p[0].iov_base = (uint8_t *)p[0].iov_base + mid_head;
+p[0].iov_len -= mid_head;
+p[mid_niov - 1].iov_len -= mid_tail;
+p += mid_niov;
+}
+
+if (tail_len) {
+p->iov_base = tail_buf;
+p->iov_len = tail_len;
+}
+}
+
 /*
  * Check if the contents of the iovecs are all zero
  */
@@ -374,14 +471,19 @@ bool qemu_iovec_is_zero(QEMUIOVector *qiov)
 return true;
 }
 
+void qemu_iovec_init_slice(QEMUIOVector *qiov, QEMUIOVector *source,
+   size_t offset, size_t len)
+{
+qemu_iovec_init_extended(qiov, NULL, 0, source, offset, len, NULL, 0);
+}
+
 void qemu_iovec_destroy(QEMUIOVector *qiov)
 {
-assert(qiov->nalloc != -1);
+if (qiov->nalloc != -1) {
+g_free(qiov->iov);
+}
 
-qemu_iovec_reset(qiov);
-g_free(qiov->iov);
-qiov->nalloc = 0;
-qiov->iov = NULL;
+memset(qiov, 0, sizeof(*qiov));
 }
 
 void qemu_iovec_reset(QEMUIOVec

[Qemu-devel] [PATCH v2 09/12] block/io: introduce bdrv_co_p{read, write}v_part

[Vladimir Sementsov-Ogievskiy]

Introduce extended variants of bdrv_co_preadv and bdrv_co_pwritev
with qiov_offset parameter.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/block/block_int.h |  6 ++
 block/io.c| 29 +++--
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/include/block/block_int.h b/include/block/block_int.h
index 46e17d2e2f..8b7b5d5b84 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -940,9 +940,15 @@ extern BlockDriver bdrv_qcow2;
 int coroutine_fn bdrv_co_preadv(BdrvChild *child,
 int64_t offset, unsigned int bytes, QEMUIOVector *qiov,
 BdrvRequestFlags flags);
+int coroutine_fn bdrv_co_preadv_part(BdrvChild *child,
+int64_t offset, unsigned int bytes,
+QEMUIOVector *qiov, size_t qiov_offset, BdrvRequestFlags flags);
 int coroutine_fn bdrv_co_pwritev(BdrvChild *child,
 int64_t offset, unsigned int bytes, QEMUIOVector *qiov,
 BdrvRequestFlags flags);
+int coroutine_fn bdrv_co_pwritev_part(BdrvChild *child,
+int64_t offset, unsigned int bytes,
+QEMUIOVector *qiov, size_t qiov_offset, BdrvRequestFlags flags);
 
 static inline int coroutine_fn bdrv_co_pread(BdrvChild *child,
 int64_t offset, unsigned int bytes, void *buf, BdrvRequestFlags flags)
diff --git a/block/io.c b/block/io.c
index 660c96527d..82051730fd 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1534,7 +1534,8 @@ static void bdrv_padding_destroy(BdrvRequestPadding *pad)
  *
  * Function always succeeds.
  */
-static bool bdrv_pad_request(BlockDriverState *bs, QEMUIOVector **qiov,
+static bool bdrv_pad_request(BlockDriverState *bs,
+ QEMUIOVector **qiov, size_t *qiov_offset,
  int64_t *offset, unsigned int *bytes,
  BdrvRequestPadding *pad)
 {
@@ -1543,11 +1544,12 @@ static bool bdrv_pad_request(BlockDriverState *bs, 
QEMUIOVector **qiov,
 }
 
 qemu_iovec_init_extended(&pad->local_qiov, pad->buf, pad->head,
- *qiov, 0, *bytes,
+ *qiov, *qiov_offset, *bytes,
  pad->buf + pad->buf_len - pad->tail, pad->tail);
 *bytes += pad->head + pad->tail;
 *offset -= pad->head;
 *qiov = &pad->local_qiov;
+*qiov_offset = 0;
 
 return true;
 }
@@ -1555,6 +1557,14 @@ static bool bdrv_pad_request(BlockDriverState *bs, 
QEMUIOVector **qiov,
 int coroutine_fn bdrv_co_preadv(BdrvChild *child,
 int64_t offset, unsigned int bytes, QEMUIOVector *qiov,
 BdrvRequestFlags flags)
+{
+return bdrv_co_preadv_part(child, offset, bytes, qiov, 0, flags);
+}
+
+int coroutine_fn bdrv_co_preadv_part(BdrvChild *child,
+int64_t offset, unsigned int bytes,
+QEMUIOVector *qiov, size_t qiov_offset,
+BdrvRequestFlags flags)
 {
 BlockDriverState *bs = child->bs;
 BdrvTrackedRequest req;
@@ -1575,12 +1585,12 @@ int coroutine_fn bdrv_co_preadv(BdrvChild *child,
 flags |= BDRV_REQ_COPY_ON_READ;
 }
 
-bdrv_pad_request(bs, &qiov, &offset, &bytes, &pad);
+bdrv_pad_request(bs, &qiov, &qiov_offset, &offset, &bytes, &pad);
 
 tracked_request_begin(&req, bs, offset, bytes, BDRV_TRACKED_READ);
 ret = bdrv_aligned_preadv(child, &req, offset, bytes,
   bs->bl.request_alignment,
-  qiov, 0, flags);
+  qiov, qiov_offset, flags);
 tracked_request_end(&req);
 bdrv_dec_in_flight(bs);
 
@@ -1943,6 +1953,13 @@ out:
 int coroutine_fn bdrv_co_pwritev(BdrvChild *child,
 int64_t offset, unsigned int bytes, QEMUIOVector *qiov,
 BdrvRequestFlags flags)
+{
+return bdrv_co_pwritev_part(child, offset, bytes, qiov, 0, flags);
+}
+
+int coroutine_fn bdrv_co_pwritev_part(BdrvChild *child,
+int64_t offset, unsigned int bytes, QEMUIOVector *qiov, size_t qiov_offset,
+BdrvRequestFlags flags)
 {
 BlockDriverState *bs = child->bs;
 BdrvTrackedRequest req;
@@ -1974,14 +1991,14 @@ int coroutine_fn bdrv_co_pwritev(BdrvChild *child,
 goto out;
 }
 
-if (bdrv_pad_request(bs, &qiov, &offset, &bytes, &pad)) {
+if (bdrv_pad_request(bs, &qiov, &qiov_offset, &offset, &bytes, &pad)) {
 mark_request_serialising(&req, align);
 wait_serialising_requests(&req);
 bdrv_padding_rmw_read(child, &req, &pad, false);
 }
 
 ret = bdrv_aligned_pwritev(child, &req, offset, bytes, align,
-   qiov, 0, flags);
+   qiov, qiov_offset, flags);
 
 bdrv_padding_destroy(&pad);
 
-- 
2.18.0

[Qemu-devel] [PATCH v2 07/12] block/io: bdrv_aligned_preadv: use and support qiov_offset

[Vladimir Sementsov-Ogievskiy]

Use and support new API in bdrv_co_do_copy_on_readv.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/io.c | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/block/io.c b/block/io.c
index a4f67aca47..0cc80e2d5a 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1309,7 +1309,7 @@ err:
  */
 static int coroutine_fn bdrv_aligned_preadv(BdrvChild *child,
 BdrvTrackedRequest *req, int64_t offset, unsigned int bytes,
-int64_t align, QEMUIOVector *qiov, int flags)
+int64_t align, QEMUIOVector *qiov, size_t qiov_offset, int flags)
 {
 BlockDriverState *bs = child->bs;
 int64_t total_bytes, max_bytes;
@@ -1320,7 +1320,6 @@ static int coroutine_fn bdrv_aligned_preadv(BdrvChild 
*child,
 assert(is_power_of_2(align));
 assert((offset & (align - 1)) == 0);
 assert((bytes & (align - 1)) == 0);
-assert(!qiov || bytes == qiov->size);
 assert((bs->open_flags & BDRV_O_NO_IO) == 0);
 max_transfer = QEMU_ALIGN_DOWN(MIN_NON_ZERO(bs->bl.max_transfer, INT_MAX),
align);
@@ -1357,7 +1356,8 @@ static int coroutine_fn bdrv_aligned_preadv(BdrvChild 
*child,
 }
 
 if (!ret || pnum != bytes) {
-ret = bdrv_co_do_copy_on_readv(child, offset, bytes, qiov, 0);
+ret = bdrv_co_do_copy_on_readv(child, offset, bytes,
+   qiov, qiov_offset);
 goto out;
 }
 }
@@ -1371,7 +1371,7 @@ static int coroutine_fn bdrv_aligned_preadv(BdrvChild 
*child,
 
 max_bytes = ROUND_UP(MAX(0, total_bytes - offset), align);
 if (bytes <= max_bytes && bytes <= max_transfer) {
-ret = bdrv_driver_preadv(bs, offset, bytes, qiov, 0, 0);
+ret = bdrv_driver_preadv(bs, offset, bytes, qiov, qiov_offset, 0);
 goto out;
 }
 
@@ -1379,17 +1379,12 @@ static int coroutine_fn bdrv_aligned_preadv(BdrvChild 
*child,
 int num;
 
 if (max_bytes) {
-QEMUIOVector local_qiov;
-
 num = MIN(bytes_remaining, MIN(max_bytes, max_transfer));
 assert(num);
-qemu_iovec_init(&local_qiov, qiov->niov);
-qemu_iovec_concat(&local_qiov, qiov, bytes - bytes_remaining, num);
 
 ret = bdrv_driver_preadv(bs, offset + bytes - bytes_remaining,
- num, &local_qiov, 0, 0);
+ num, qiov, bytes - bytes_remaining, 0);
 max_bytes -= num;
-qemu_iovec_destroy(&local_qiov);
 } else {
 num = bytes_remaining;
 ret = qemu_iovec_memset(qiov, bytes - bytes_remaining, 0,
@@ -1486,7 +1481,7 @@ static int bdrv_padding_rmw_read(BdrvChild *child,
 
 bdrv_debug_event(bs, BLKDBG_PWRITEV_RMW_HEAD);
 ret = bdrv_aligned_preadv(child, req, req->overlap_offset, bytes,
-  align, &local_qiov, 0);
+  align, &local_qiov, 0, 0);
 if (ret < 0) {
 return ret;
 }
@@ -1504,7 +1499,7 @@ static int bdrv_padding_rmw_read(BdrvChild *child,
 ret = bdrv_aligned_preadv(
 child, req,
 req->overlap_offset + req->overlap_bytes - align,
-align, align, &local_qiov, 0);
+align, align, &local_qiov, 0, 0);
 if (ret < 0) {
 return ret;
 }
@@ -1585,7 +1580,7 @@ int coroutine_fn bdrv_co_preadv(BdrvChild *child,
 tracked_request_begin(&req, bs, offset, bytes, BDRV_TRACKED_READ);
 ret = bdrv_aligned_preadv(child, &req, offset, bytes,
   bs->bl.request_alignment,
-  qiov, flags);
+  qiov, 0, flags);
 tracked_request_end(&req);
 bdrv_dec_in_flight(bs);
 
-- 
2.18.0