Re: [Qemu-devel] [PATCH v3 08/12] hw/pci: introduce pci_device_notify_iommu()

2018-03-02 Thread Paolo Bonzini
On 01/03/2018 11:33, Liu, Yi L wrote:
> +pci_device_notify_iommu(pdev, PCI_NTY_DEV_ADD);
> +
>  pci_setup_sva_ops(pdev, _pci_sva_ops);
>  
>  return;
> @@ -3134,6 +3136,7 @@ static void vfio_exitfn(PCIDevice *pdev)
>  {
>  VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev);
>  
> +pci_device_notify_iommu(pdev, PCI_NTY_DEV_DEL);

Please make the names longer: PCI_IOMMU_NOTIFY_DEVICE_ADDED and
PCI_IOMMU_NOTIFY_DEVICE_REMOVED.  (This is independent of my other
remark, about doing this in generic PCI code for all devices that
register SVA ops).

Thanks,

Paolo



Re: [Qemu-devel] [PATCH V7 1/4] rules: Move cross compilation auto detection functions to rules.mak

2018-03-02 Thread Laurent Vivier
On 28/02/2018 19:02, Wei Huang wrote:
> This patch moves the auto detection functions for cross compilation from
> roms/Makefile to rules.mak. So the functions can be shared among Makefiles
> in QEMU.
> 
> Signed-off-by: Wei Huang 
> Reviewed-by: Andrew Jones 
> ---
>  roms/Makefile | 24 +++-
>  rules.mak | 15 +++
>  2 files changed, 22 insertions(+), 17 deletions(-)
> 
> diff --git a/roms/Makefile b/roms/Makefile
> index b5e5a69e91..e972c65333 100644
> --- a/roms/Makefile
> +++ b/roms/Makefile
> @@ -21,23 +21,6 @@ pxe-rom-virtio   efi-rom-virtio   : DID := 1000
>  pxe-rom-vmxnet3  efi-rom-vmxnet3  : VID := 15ad
>  pxe-rom-vmxnet3  efi-rom-vmxnet3  : DID := 07b0
>  
> -#
> -# cross compiler auto detection
> -#
> -path := $(subst :, ,$(PATH))
> -system := $(shell uname -s | tr "A-Z" "a-z")
> -
> -# first find cross binutils in path
> -find-cross-ld = $(firstword $(wildcard $(patsubst 
> %,%/$(1)-*$(system)*-ld,$(path
> -# then check we have cross gcc too
> -find-cross-gcc = $(firstword $(wildcard $(patsubst %ld,%gcc,$(call 
> find-cross-ld,$(1)
> -# finally strip off path + toolname so we get the prefix
> -find-cross-prefix = $(subst gcc,,$(notdir $(call find-cross-gcc,$(1
> -
> -powerpc64_cross_prefix := $(call find-cross-prefix,powerpc64)
> -powerpc_cross_prefix := $(call find-cross-prefix,powerpc)
> -x86_64_cross_prefix := $(call find-cross-prefix,x86_64)
> -
>  # tag our seabios builds
>  SEABIOS_EXTRAVERSION="-prebuilt.qemu-project.org"
>  
> @@ -66,6 +49,13 @@ default:
>   @echo "  skiboot-- update skiboot.lid"
>   @echo "  u-boot.e500-- update u-boot.e500"
>  
> +SRC_PATH=..
> +include $(SRC_PATH)/rules.mak
> +
> +powerpc64_cross_prefix := $(call find-cross-prefix,powerpc64)
> +powerpc_cross_prefix := $(call find-cross-prefix,powerpc)
> +x86_64_cross_prefix := $(call find-cross-prefix,x86_64)
> +
>  bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k
>   cp seabios/builds/seabios-128k/bios.bin ../pc-bios/bios.bin
>   cp seabios/builds/seabios-256k/bios.bin ../pc-bios/bios-256k.bin
> diff --git a/rules.mak b/rules.mak
> index 6e943335f3..ef8adee3f8 100644
> --- a/rules.mak
> +++ b/rules.mak
> @@ -62,6 +62,21 @@ expand-objs = $(strip $(sort $(filter %.o,$1)) \
>$(foreach o,$(filter %.mo,$1),$($o-objs)) \
>$(filter-out %.o %.mo,$1))
>  
> +# Cross compilation auto detection. Use find-cross-prefix to detect the
> +# target archtecture's prefix, and then append it to the build tool or pass
> +# it to CROSS_COMPILE directly. Here is one example:
> +#  x86_64_cross_prefix := $(call find-cross-prefix,x86_64)
> +#  $(x86_64_cross_prefix)gcc -c test.c -o test.o
> +#  make -C testdir CROSS_COMPILE=$(x86_64_cross_prefix)
> +cross-search-path := $(subst :, ,$(PATH))
> +cross-host-system := $(shell uname -s | tr "A-Z" "a-z")
> +
> +find-cross-ld = $(firstword $(wildcard $(patsubst \
> +
> %,%/$(1)-*$(cross-host-system)*-ld,$(cross-search-path
> +find-cross-gcc = $(firstword $(wildcard \
> +$(patsubst %ld,%gcc,$(call find-cross-ld,$(1)
> +find-cross-prefix = $(subst gcc,,$(notdir $(call find-cross-gcc,$(1
> +
>  %.o: %.c
>   $(call quiet-command,$(CC) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
>  $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) \
> 

With this patch, "make slof" fails:

  git submodule init roms/SLOF
  git submodule update roms/SLOF
  cd roms
  make slof
...
make[4]: Entering directory
'/home/lvivier/Projects/qemu-upstream/roms/SLOF/lib/libnvram'
[CC]Makefile.dep
powerpc64-linux-gnu-ar: nvram.o: No such file or directory
make[4]: *** [Makefile:31: ../libnvram.a] Error 1

Perhaps rules.mak defines values inherited by SLOF makefiles that are
incompatible?

Thanks,
Laurent





Re: [Qemu-devel] [PATCH 1/2] net: add e1000e model to the "simple" -net/-nic options

2018-03-02 Thread Thomas Huth
On 02.03.2018 16:51, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini 
> ---
>  hw/pci/pci.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index e006b6ac71..af3c85a46f 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -1822,6 +1822,7 @@ static const char * const pci_nic_models[] = {
>  "i82559er",
>  "rtl8139",
>  "e1000",
> +"e1000e",
>  "pcnet",
>  "virtio",
>  "sungem",
> @@ -1835,6 +1836,7 @@ static const char * const pci_nic_names[] = {
>  "i82559er",
>  "rtl8139",
>  "e1000",
> +"e1000e",
>  "pcnet",
>  "virtio-net-pci",
>  "sungem",

I think it would be better and more consisten to finally fix this mess
and automatically allow all devices in the category
DEVICE_CATEGORY_NETWORK that are derived from TYPE_PCI_DEVICE, instead
of manually maintaining this list here...?

 Thomas



Re: [Qemu-devel] [PATCH 2/2] q35: change default NIC to e1000e

2018-03-02 Thread Thomas Huth
On 02.03.2018 16:51, Paolo Bonzini wrote:
> The e1000 NIC is getting old and is not a very good default for a
> PCIe machine type.  Change it to e1000e, which should be supported
> by a good number of guests.

Basically a good idea, but you can only do that for new machine types
(pc-q35-2.12 and later), otherwise migration from an older version will
fail if the user tries to migrate with the default model.

 Thomas



Re: [Qemu-devel] [PATCH v1 2/2] hw/arm: Set the core count for Xilinx's ZynqMP

2018-03-02 Thread Peter Maydell
On 2 March 2018 at 17:06, Alistair Francis  wrote:
> Set the ARM CPU core count property for the A53's attached to the Xilnx
> ZynqMP machine.
>
> Signed-off-by: Alistair Francis 
> ---
>
>  hw/arm/xlnx-zynqmp.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
> index 69227fd4c9..465796e97c 100644
> --- a/hw/arm/xlnx-zynqmp.c
> +++ b/hw/arm/xlnx-zynqmp.c
> @@ -282,6 +282,8 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>   s->virt, "has_el2", NULL);
>  object_property_set_int(OBJECT(>apu_cpu[i]), GIC_BASE_ADDR,
>  "reset-cbar", _abort);
> +object_property_set_int(OBJECT(>apu_cpu[i]), num_apus,
> +"core-count", _abort);
>  object_property_set_bool(OBJECT(>apu_cpu[i]), true, "realized",
>   );
>  if (err) {

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [Qemu-devel] [PATCH v3] vmgenid: allow VM Generation ID modification via QMP/HMP

2018-03-02 Thread Benjamin Warren via Qemu-devel
On Fri, Mar 2, 2018 at 2:57 AM, Daniel P. Berrangé 
wrote:

> On Fri, Mar 02, 2018 at 10:37:20AM +0200, Or Idgar wrote:
> > From: Or Idgar 
> >
> > This patch allow changing the Virtual Machine Generation
> > ID through QMP/HMP while the vm guest is running.
> > the spec (http://go.microsoft.com/fwlink/?LinkId=260709)
> > mentions that "when the generation ID changes, execute an
> > ACPI Notify operation on the generation ID device".
> > To test it we need the ability to set the generation ID
> > online. QMP/HMP allows that.
>
> If we want to test vmgenid, why don't we simply trigger one of
> the mgmt actions that are required to change vmgenid. eg do a
> savevm, followed by a loadvm to restore from snapshot. This would
> be better testing of the real world usage of this feature.
>
> I agree.  Verifying functionality in a Windows guest is tricky, but in
Linux you can build and load this (old and badly written) device driver:

https://github.com/ben-skyportsystems/vmgenid-test

You should see the 'notices' number increment after restoring a snapshot.

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

regards,
Ben


Re: [Qemu-devel] [PATCH 2/4] rocker: drop local duplex definitions

2018-03-02 Thread Michael S. Tsirkin
On Thu, Mar 01, 2018 at 10:46:34PM -0500, Jason Baron wrote:
> Make use of duplex definitions from net/eth.h.
> 
> Signed-off-by: Jason Baron 
> Cc: "Michael S. Tsirkin" 
> Cc: Jason Wang 
> Cc: Jiri Pirko 
> Cc: virtio-...@lists.oasis-open.org
> ---
>  hw/net/rocker/rocker_fp.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/hw/net/rocker/rocker_fp.c b/hw/net/rocker/rocker_fp.c
> index 4b3c984..13a14a0 100644
> --- a/hw/net/rocker/rocker_fp.c
> +++ b/hw/net/rocker/rocker_fp.c
> @@ -16,17 +16,13 @@
>  
>  #include "qemu/osdep.h"
>  #include "net/clients.h"
> +#include "net/eth.h"
>  
>  #include "rocker.h"
>  #include "rocker_hw.h"
>  #include "rocker_fp.h"
>  #include "rocker_world.h"
>  
> -enum duplex {
> -DUPLEX_HALF = 0,
> -DUPLEX_FULL
> -};
> -

This is hardware emulation, so I actually suspect it
should be renamed ROCKER_FP_HALF/ROCKER_FP_FULL.

>  struct fp_port {
>  Rocker *r;
>  World *world;
> -- 
> 2.7.4



Re: [Qemu-devel] [PATCH v3 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

2018-03-02 Thread Michael S. Tsirkin
On Fri, Mar 02, 2018 at 04:47:29PM +0800, Wei Wang wrote:
> The new feature enables the virtio-balloon device to receive hints of
> guest free pages from the free page vq. Callers call the
> free_page_start API to start the reporting, which creates a thread to
> poll for free page hints. The free_page_stop API stops the reporting and
> makes the thread exit.
> 
> Signed-off-by: Wei Wang 
> Signed-off-by: Liang Li 
> CC: Michael S. Tsirkin 
> CC: Dr. David Alan Gilbert 
> CC: Juan Quintela 
> ---
>  balloon.c   |  49 +--
>  hw/virtio/virtio-balloon.c  | 172 
> +---
>  include/hw/virtio/virtio-balloon.h  |  14 +-
>  include/standard-headers/linux/virtio_balloon.h |   7 +
>  include/sysemu/balloon.h|  15 ++-
>  5 files changed, 228 insertions(+), 29 deletions(-)
> 
> diff --git a/balloon.c b/balloon.c
> index d8dd6fe..b0b0749 100644
> --- a/balloon.c
> +++ b/balloon.c
> @@ -36,6 +36,9 @@
>  
>  static QEMUBalloonEvent *balloon_event_fn;
>  static QEMUBalloonStatus *balloon_stat_fn;
> +static QEMUBalloonFreePageSupport *balloon_free_page_support_fn;
> +static QEMUBalloonFreePageStart *balloon_free_page_start_fn;
> +static QEMUBalloonFreePageStop *balloon_free_page_stop_fn;
>  static void *balloon_opaque;
>  static bool balloon_inhibited;
>  
> @@ -64,19 +67,42 @@ static bool have_balloon(Error **errp)
>  return true;
>  }
>  
> -int qemu_add_balloon_handler(QEMUBalloonEvent *event_func,
> - QEMUBalloonStatus *stat_func, void *opaque)
> +bool balloon_free_page_support(void)
>  {
> -if (balloon_event_fn || balloon_stat_fn || balloon_opaque) {
> -/* We're already registered one balloon handler.  How many can
> - * a guest really have?
> - */
> -return -1;
> +return balloon_free_page_support_fn &&
> +   balloon_free_page_support_fn(balloon_opaque);
> +}
> +
> +void balloon_free_page_start(void)
> +{
> +balloon_free_page_start_fn(balloon_opaque);
> +}
> +
> +void balloon_free_page_stop(void)
> +{
> +balloon_free_page_stop_fn(balloon_opaque);
> +}
> +
> +void qemu_add_balloon_handler(QEMUBalloonEvent *event_fn,
> +  QEMUBalloonStatus *stat_fn,
> +  QEMUBalloonFreePageSupport 
> *free_page_support_fn,
> +  QEMUBalloonFreePageStart *free_page_start_fn,
> +  QEMUBalloonFreePageStop *free_page_stop_fn,
> +  void *opaque)
> +{
> +if (balloon_event_fn || balloon_stat_fn || balloon_free_page_support_fn 
> ||
> +balloon_free_page_start_fn || balloon_free_page_stop_fn ||
> +balloon_opaque) {
> +/* We already registered one balloon handler. */
> +return;
>  }
> -balloon_event_fn = event_func;
> -balloon_stat_fn = stat_func;
> +
> +balloon_event_fn = event_fn;
> +balloon_stat_fn = stat_fn;
> +balloon_free_page_support_fn = free_page_support_fn;
> +balloon_free_page_start_fn = free_page_start_fn;
> +balloon_free_page_stop_fn = free_page_stop_fn;
>  balloon_opaque = opaque;
> -return 0;
>  }
>  
>  void qemu_remove_balloon_handler(void *opaque)
> @@ -86,6 +112,9 @@ void qemu_remove_balloon_handler(void *opaque)
>  }
>  balloon_event_fn = NULL;
>  balloon_stat_fn = NULL;
> +balloon_free_page_support_fn = NULL;
> +balloon_free_page_start_fn = NULL;
> +balloon_free_page_stop_fn = NULL;
>  balloon_opaque = NULL;
>  }
>  
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index 4822449..4607879 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -31,6 +31,7 @@
>  
>  #include "hw/virtio/virtio-bus.h"
>  #include "hw/virtio/virtio-access.h"
> +#include "migration/misc.h"
>  
>  #define BALLOON_PAGE_SIZE  (1 << VIRTIO_BALLOON_PFN_SHIFT)
>  
> @@ -308,6 +309,100 @@ out:
>  }
>  }
>  
> +static void *virtio_balloon_poll_free_page_hints(void *opaque)
> +{
> +VirtQueueElement *elem;
> +VirtIOBalloon *dev = opaque;
> +VirtQueue *vq = dev->free_page_vq;
> +uint32_t id;
> +size_t size;
> +
> +/*
> + * Poll the vq till the status changed to STOP. This happens when
> + * the guest finishes reporting hints or the migration thread actively
> + * stops the reporting.
> + */
> +while (dev->free_page_report_status != FREE_PAGE_REPORT_S_STOP) {
> +elem = virtqueue_pop(vq, sizeof(VirtQueueElement));
> +if (!elem) {
> +continue;
> +}
> +
> +if (elem->out_num) {
> +size = iov_to_buf(elem->out_sg, elem->out_num, 0, , 
> sizeof(id));
> +virtqueue_push(vq, elem, size);
> +g_free(elem);
> +if (unlikely(size != sizeof(id))) {
> 

Re: [Qemu-devel] [PATCH v3 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

2018-03-02 Thread Michael S. Tsirkin
On Fri, Mar 02, 2018 at 04:47:29PM +0800, Wei Wang wrote:
> diff --git a/include/sysemu/balloon.h b/include/sysemu/balloon.h
> index af49e19..16a2aae 100644
> --- a/include/sysemu/balloon.h
> +++ b/include/sysemu/balloon.h

...

> +typedef void (QEMUBalloonFreePageStart)(void *opaque);
> +typedef void (QEMUBalloonFreePageStop)(void *opaque);

So I think the rule is that no bitmap sync must happen
between these two, otherwise a hint might arrive and
override the sync output.

Should be documented I think.

-- 
MST



[Qemu-devel] [RFC PATCH 0/2] change q35 default NIC to e1000e

2018-03-02 Thread Paolo Bonzini
The Intel 82574 NIC has better performance and more features than
the aging e1000 (aka 82540), for example MSI-X.  This patch chooses it
by default for the Q35 machine type.

Drivers for 82574 were added first to Linux 2.6.27 (2008) and Windows
2008 R2.  This does mean that Windows 2008 will not work anymore with Q35
machine types and a default "-net nic -net xxx" network configuration;
it did work before because it does have an AHCI driver.  However, Windows
2008 has been declared out of main stream support in 2015.  It will
get out of extended support in 2020.  Windows 2008 R2 has the same end
of support dates and, since the two are basically Vista vs. Windows 7,
R2 probably is more popular.

Opinions?

Paolo

Paolo Bonzini (2):
  net: add e1000e model to the "simple" -net/-nic options
  q35: change default NIC to e1000e

 hw/i386/pc.c | 5 +++--
 hw/i386/pc_piix.c| 2 +-
 hw/i386/pc_q35.c | 2 +-
 hw/pci/pci.c | 2 ++
 include/hw/i386/pc.h | 2 +-
 5 files changed, 8 insertions(+), 5 deletions(-)

-- 
2.14.3




[Qemu-devel] [PATCH 1/2] net: add e1000e model to the "simple" -net/-nic options

2018-03-02 Thread Paolo Bonzini
Signed-off-by: Paolo Bonzini 
---
 hw/pci/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index e006b6ac71..af3c85a46f 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1822,6 +1822,7 @@ static const char * const pci_nic_models[] = {
 "i82559er",
 "rtl8139",
 "e1000",
+"e1000e",
 "pcnet",
 "virtio",
 "sungem",
@@ -1835,6 +1836,7 @@ static const char * const pci_nic_names[] = {
 "i82559er",
 "rtl8139",
 "e1000",
+"e1000e",
 "pcnet",
 "virtio-net-pci",
 "sungem",
-- 
2.14.3





Re: [Qemu-devel] [PULL v3 00/30] QAPI patches for 2018-03-01

2018-03-02 Thread Peter Maydell
On 2 March 2018 at 15:31, Eric Blake  wrote:
> The following changes since commit 2e7b766594e17f786a6b2e5be690bc5b43ce6036:
>
>   Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2018-03-01' into 
> staging (2018-03-02 12:39:13 +)
>
> are available in the Git repository at:
>
>   git://repo.or.cz/qemu/ericb.git tags/pull-qapi-2018-03-01-v3
>
> for you to fetch changes up to cfe6a7fc6da20349ef62966c437f18ed6c49fcd5:
>
>   qapi: Don't create useless directory qapi-generated (2018-03-02 09:01:40 
> -0600)
>
> v3: (attempt to) fix warnings about empty .o files on OSX toolchain [Peter]
> (sending just the changed patch)
>
> 
> qapi patches for 2018-03-01
>
> - Markus Armbruster: Modularize generated QAPI code
>

As I suspected, this isn't sufficient to silence the warnings.

thanks
-- PMM



Re: [Qemu-devel] [PATCH v1 1/2] target/arm: Add a cluster size property

2018-03-02 Thread Alistair Francis
On Fri, Mar 2, 2018 at 9:31 AM, Peter Maydell  wrote:
> On 2 March 2018 at 17:06, Alistair Francis  
> wrote:
>
> Subject should say "core count" rather than "cluster size" ?

Yes, that was left over. I'll fix.

>
>> The cortex A53 TRM specifices that bits 24 and 25 of the L2CTLR register
>
> "specifies"
>
>> specify the number of cores present and not the number of processors. To
>
> "the number of cores in the processor, not the total number of cores
> in the system".

Fixed these.

>
>> report this correctly on machines with multiple CPU clusters (ARM's
>> big.LITTLE or Xilinx's ZynqMP) we need to allow the machine to overwrite
>> this value. To do this let's add an optional property.
>>
>> Signed-off-by: Alistair Francis 
>> ---
>>
>>  target/arm/cpu.h   |  5 +
>>  target/arm/cpu.c   |  1 +
>>  target/arm/cpu64.c | 11 +--
>>  3 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
>> index 8dd6b788df..3fa8fdad21 100644
>> --- a/target/arm/cpu.h
>> +++ b/target/arm/cpu.h
>> @@ -745,6 +745,11 @@ struct ARMCPU {
>>  /* Uniprocessor system with MP extensions */
>>  bool mp_is_up;
>>
>> +/* Specify the number of cores in this CPU cluster. Used for the L2CTLR
>> + * register.
>> + */
>> +int32_t core_count;
>> +
>>  /* The instance init functions for implementation-specific subclasses
>>   * set these fields to specify the implementation-dependent values of
>>   * various constant registers and reset values of non-constant
>> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
>> index 6b77aaa445..7a17ba1418 100644
>> --- a/target/arm/cpu.c
>> +++ b/target/arm/cpu.c
>> @@ -1765,6 +1765,7 @@ static Property arm_cpu_properties[] = {
>>  DEFINE_PROP_UINT64("mp-affinity", ARMCPU,
>>  mp_affinity, ARM64_AFFINITY_INVALID),
>>  DEFINE_PROP_INT32("node-id", ARMCPU, node_id, CPU_UNSET_NUMA_NODE_ID),
>> +DEFINE_PROP_INT32("core-count", ARMCPU, core_count, -1),
>>  DEFINE_PROP_END_OF_LIST()
>>  };
>>
>> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
>> index 4228713b19..5e5ae44aeb 100644
>> --- a/target/arm/cpu64.c
>> +++ b/target/arm/cpu64.c
>> @@ -42,8 +42,15 @@ static inline void unset_feature(CPUARMState *env, int 
>> feature)
>>  #ifndef CONFIG_USER_ONLY
>>  static uint64_t a57_a53_l2ctlr_read(CPUARMState *env, const ARMCPRegInfo 
>> *ri)
>>  {
>> -/* Number of processors is in [25:24]; otherwise we RAZ */
>> -return (smp_cpus - 1) << 24;
>> +ARMCPU *cpu = arm_env_get_cpu(env);
>> +
>> +/* Number of cores is in [25:24]; otherwise we RAZ */
>> +if (cpu->core_count == -1) {
>> +/* No core_count specified, default to smp_cpus. */
>> +return (smp_cpus - 1) << 24;
>> +} else {
>> +return (cpu->core_count - 1) << 24;
>> +}
>>  }
>>  #endif
>
> I think having arm_cpu_realizefn do
> if (cpu->core_count == -1) {
> cpu->core_count = smp_cpus;
> }
>
> would be neater than doing that check when the register is read.

Ok will fix. I'll send a V2 out straight away, as today is my last day
and it'd be great if I could get this done.

Alistair

>
> thanks
> -- PMM



[Qemu-devel] [PATCH 0/1] FOLL_NOWAIT and get_user_pages_unlocked

2018-03-02 Thread Andrea Arcangeli
Hello,

KVM is hanging on postcopy live migration.

David tracked it down to commit
ce53053ce378c21e7ffc45241fd67d6ee79daa2b and the problem is pretty
obvious then.

Either we teach get_user_pages_locked/unlocked to handle FOLL_NOWAIT
(so faultin_nopage works right even when the nonblocking pointer is
not NULL) or we need to revert part of commit
ce53053ce378c21e7ffc45241fd67d6ee79daa2b and keep using FOLL_NOWAIT
only as parameter to get_user_pages (which won't ever set nonblocking
pointer to non-NULL). I suppose the former approach is preferred to be
more robust.

Thanks,
Andrea

Andrea Arcangeli (1):
  mm: gup: teach get_user_pages_unlocked to handle FOLL_NOWAIT

 mm/gup.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)




[Qemu-devel] [PATCH 1/1] mm: gup: teach get_user_pages_unlocked to handle FOLL_NOWAIT

2018-03-02 Thread Andrea Arcangeli
KVM is hanging during postcopy live migration with userfaultfd because
get_user_pages_unlocked is not capable to handle FOLL_NOWAIT.

Earlier FOLL_NOWAIT was only ever passed to get_user_pages.

Specifically faultin_page (the callee of get_user_pages_unlocked
caller) doesn't know that if FAULT_FLAG_RETRY_NOWAIT was set in the
page fault flags, when VM_FAULT_RETRY is returned, the mmap_sem wasn't
actually released (even if nonblocking is not NULL). So it sets
*nonblocking to zero and the caller won't release the mmap_sem
thinking it was already released, but it wasn't because of
FOLL_NOWAIT.

Reported-by: Dr. David Alan Gilbert 
Tested-by: Dr. David Alan Gilbert 
Signed-off-by: Andrea Arcangeli 
---
 mm/gup.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 1b46e6e74881..6afae32571ca 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -516,7 +516,7 @@ static int faultin_page(struct task_struct *tsk, struct 
vm_area_struct *vma,
}
 
if (ret & VM_FAULT_RETRY) {
-   if (nonblocking)
+   if (nonblocking && !(fault_flags & FAULT_FLAG_RETRY_NOWAIT))
*nonblocking = 0;
return -EBUSY;
}
@@ -890,7 +890,10 @@ static __always_inline long __get_user_pages_locked(struct 
task_struct *tsk,
break;
}
if (*locked) {
-   /* VM_FAULT_RETRY didn't trigger */
+   /*
+* VM_FAULT_RETRY didn't trigger or it was a
+* FOLL_NOWAIT.
+*/
if (!pages_done)
pages_done = ret;
break;



Re: [Qemu-devel] [PATCH 1/4] eth: add speed and duplex definitions

2018-03-02 Thread Michael S. Tsirkin
On Thu, Mar 01, 2018 at 10:46:33PM -0500, Jason Baron wrote:
> Pull in definitions for SPEED_UNKNOWN, DUPLEX_UNKNOWN, DUPLEX_HALF,
> and DUPLEX_FULL.
> 
> Signed-off-by: Jason Baron 
> Cc: "Michael S. Tsirkin" 
> Cc: Jason Wang 
> Cc: virtio-...@lists.oasis-open.org
> ---
>  include/net/eth.h | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/net/eth.h b/include/net/eth.h
> index 09054a5..9843678 100644
> --- a/include/net/eth.h
> +++ b/include/net/eth.h
> @@ -417,4 +417,11 @@ bool
>  eth_parse_ipv6_hdr(const struct iovec *pkt, int pkt_frags,
> size_t ip6hdr_off, eth_ip6_hdr_info *info);
>  
> +/* ethtool defines - from linux/ethtool.h */
> +#define SPEED_UNKNOWN   -1
> +
> +#define DUPLEX_HALF 0x00
> +#define DUPLEX_FULL 0x01
> +#define DUPLEX_UNKNOWN  0xff
> +
>  #endif

While that's not a lot, I think we should import linux/ethtool.h into
include/standard-headers/linux/ using scripts/update-linux-headers.sh

> -- 
> 2.7.4



Re: [Qemu-devel] [Qemu-ppc] [PULL 00/24] ppc-for-2.12 queue 20180302

2018-03-02 Thread BALATON Zoltan

On Fri, 2 Mar 2018, Peter Maydell wrote:

On 2 March 2018 at 06:03, David Gibson <da...@gibson.dropbear.id.au> wrote:

The following changes since commit 0dc8ae5e8e693737dfe65ba02d0c6eccb58a9c67:

  Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20180301-v2' into 
staging (2018-03-01 17:08:16 +)

are available in the Git repository at:

  git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180302

for you to fetch changes up to 57ae75b2e401f1d04f37a8cd26212eb3134c51a6:

  hw/ppc/spapr,e500: Use new property "stdout-path" for boot console 
(2018-03-02 12:24:44 +1100)


ppc patch queue 2018-03-02

Here's the next batch of accumulated spapr and ppc patches.
Highlights are:
* New Sam460ex machine type
* Yet more fixes related to vcpu id allocation for spapr
* Numerous macio cleanupsr
* Some enhancements to the Spectre/Meltdown fixes for pseries,
  allowing use of a better mitigation for indirect branch based
  exploits
* New pseries machine types with Spectre/Meltdown mitigations
  enabled (stop gap until libvirt and management understands the
  machine options)
* A handful of other fixes



Hi. This generates a compile error from some compilers in my test set
(I think just the older gccs):

/home/petmay01/linaro/qemu-for-merges/hw/ppc/ppc440_uc.c: In function
‘ppc460ex_pcie_realize’:
/home/petmay01/linaro/qemu-for-merges/hw/ppc/ppc440_uc.c:1054:5:
error: ‘id’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
snprintf(buf, sizeof(buf), "pcie%d-io", id);
^
cc1: all warnings being treated as errors

Looks like a valid complaint to me -- the realize function
should check that dcrn_base was set to a valid value, fail
realize if it wasn't, and have a 'default:' case in the
switch with g_assert_not_reached().


I've sent an updated patch (v3) that should fix this.

Thank you,
BALATON Zoltan


Re: [Qemu-devel] [PATCH v2 5/5] s390x/cpumodel: Set up CPU model for AP device support

2018-03-02 Thread Tony Krowiak

On 03/01/2018 09:12 AM, Pierre Morel wrote:

On 28/02/2018 12:40, Cornelia Huck wrote:

On Wed, 28 Feb 2018 11:26:30 +0100
David Hildenbrand  wrote:


Then I request the following change in KVM:

If KVM_S390_VM_CPU_FEAT_AP is enabled in KVM, ECA.28 is _always_ set
(not just if an AP device is configured). This especially makes 
things a

lot easier when it comes to handling hotplugged CPUs and avoiding race
conditions when enabling these bits as mentioned in the KVM series.

KVM_S390_VM_CPU_FEAT_AP == AP instructions available for the guest
(don't throw an operation exception).

So this feature then really is guest ABI. The instructions are
available. If there is no device configured, bad luck.

Sounds sensible from my POV.



I have a concern with this proposition and with the original code:

1) ap=on is a guest ABI feature saying to the guest you can use AP 
instructions


2) How we provide AP instructions to the guest can be done in three 
different ways:

 - SIE Interpretation
 - interception with VFIO
 - interception with emulation

3) We implement this with a device in QEMU and a certain level kernel 
support.


It seems possible to set or not ECA.28 , based on the type of kernel 
device:

- SIE interpretation -> MATRIX KVM device -> ECA.28
- Interception with VFIO and virtualization -> no ECA.28
- interception with emulation -> no ECA.28

I understand the concern with the vCPU but I think we can handle it 
with an indirect variable

like:

SIE interpretation Device + KVM_S390_VM_CPU_FEAT_AP -> set the 
variable  ap_to_be_sie_interpreted=1

Then in vCPU initialization set ECA.28 based on this variable.

I think it let us more doors open, what is your opinion?
I've already implemented a proof of concept similar to what you suggest 
to verify whether it would.
I wasn't completely sure of the flow of control between the KVM 
notification to the device driver
and the vcpu setup. If the variable is set when the device driver is 
notified about KVM,
it has to happen before vcpu setup for this to work. I was able to 
verify that with my proof
of concept. This discussion really belongs in the KVM/kernel patches, so 
I am going to continue

the discussion of my proposal there.


Regards,

Pierre







Re: [Qemu-devel] [PATCH v2 resend] block/mirror: change the semantic of 'force' of block-job-cancel

2018-03-02 Thread John Snow


On 03/02/2018 10:39 AM, Eric Blake wrote:
> On 02/26/2018 08:05 PM, Liang Li wrote:
>> When doing drive mirror to a low speed shared storage, if there was heavy
>> BLK IO write workload in VM after the 'ready' event, drive mirror
>> block job
>> can't be canceled immediately, it would keep running until the heavy
>> BLK IO
>> workload stopped in the VM.
>>
>> Libvirt depends on the current block-job-cancel semantics, which is that
>> when used without a flag after the 'ready' event, the command blocks
>> until data is in sync.  However, these semantics are awkward in other
>> situations, for example, people may use drive mirror for realtime
>> backups while still wanting to use block live migration.  Libvirt cannot
>> start a block live migration while another drive mirror is in progress,
>> but the user would rather abandon the backup attempt as broken and
>> proceed with the live migration than be stuck waiting for the current
>> drive mirror backup to finish.
>>
>> The drive-mirror command already includes a 'force' flag, which libvirt
>> does not use, although it documented the flag as only being useful to
>> quit a job which is paused.  However, since quitting a paused job has
>> the same effect as abandoning a backup in a non-paused job (namely, the
>> destination file is not in sync, and the command completes immediately),
>> we can just improve the documentation to make the force flag obviously
>> useful.
> 
> How does this interact with John's ongoing work to redo block job
> semantics:
> https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg06167.html
> 
>>
>> Cc: Paolo Bonzini 
>> Cc: Jeff Cody 
>> Cc: Kevin Wolf 
>> Cc: Max Reitz 
>> Cc: Eric Blake 
>> Cc: John Snow 
>> Reported-by: Huaitong Han 
>> Signed-off-by: Huaitong Han 
>> Signed-off-by: Liang Li 
>> ---
> 
> But in isolation, the patch looks reasonable to me.
> 
> Reviewed-by: Eric Blake 
> 

In fairness, this patch hit the list before mine did, so...

I think it'll be OK to accommodate -- I think. It just changes the
nature of how fast the cancellation happens in mirror, which shouldn't
muck around with the general flow of job management in general. I think.

Famous last words.

--js



[Qemu-devel] [PATCH v2 0/2] Add a property to set the ARM CPU core count

2018-03-02 Thread Alistair Francis

Add an ARM CPU property which allows us to set the ARM CPU core count.

V2:
 - Fix commit message and title.
 - Move the core_count default setting logic to the arm_cpu_realize()
   function.


Alistair Francis (2):
  target/arm: Add a core count property
  hw/arm: Set the core count for Xilinx's ZynqMP

 target/arm/cpu.h | 5 +
 hw/arm/xlnx-zynqmp.c | 2 ++
 target/arm/cpu.c | 6 ++
 target/arm/cpu64.c   | 6 --
 4 files changed, 17 insertions(+), 2 deletions(-)

-- 
2.14.1




[Qemu-devel] [PATCH v2 1/2] target/arm: Add a core count property

2018-03-02 Thread Alistair Francis
The cortex A53 TRM specifies that bits 24 and 25 of the L2CTLR register
specify the number of cores in the processor, not the total number of
cores in the sytem. To report this correctly on machines with multiple
CPU clusters (ARM's big.LITTLE or Xilinx's ZynqMP) we need to allow
the machine to overwrite this value. To do this let's add an optional
property.

Signed-off-by: Alistair Francis 
---
V2:
 - Fix commit message and title.
 - Move the core_count default setting logic to the arm_cpu_realize()
   function.

 target/arm/cpu.h   | 5 +
 target/arm/cpu.c   | 6 ++
 target/arm/cpu64.c | 6 --
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 8dd6b788df..3fa8fdad21 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -745,6 +745,11 @@ struct ARMCPU {
 /* Uniprocessor system with MP extensions */
 bool mp_is_up;
 
+/* Specify the number of cores in this CPU cluster. Used for the L2CTLR
+ * register.
+ */
+int32_t core_count;
+
 /* The instance init functions for implementation-specific subclasses
  * set these fields to specify the implementation-dependent values of
  * various constant registers and reset values of non-constant
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 6b77aaa445..83590decde 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -877,6 +877,11 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
 cpu->has_mpu = false;
 }
 
+/* No core_count specified, default to smp_cpus. */
+if (cpu->core_count == -1) {
+cpu->core_count = smp_cpus;
+}
+
 if (arm_feature(env, ARM_FEATURE_PMSA) &&
 arm_feature(env, ARM_FEATURE_V7)) {
 uint32_t nr = cpu->pmsav7_dregion;
@@ -1765,6 +1770,7 @@ static Property arm_cpu_properties[] = {
 DEFINE_PROP_UINT64("mp-affinity", ARMCPU,
 mp_affinity, ARM64_AFFINITY_INVALID),
 DEFINE_PROP_INT32("node-id", ARMCPU, node_id, CPU_UNSET_NUMA_NODE_ID),
+DEFINE_PROP_INT32("core-count", ARMCPU, core_count, -1),
 DEFINE_PROP_END_OF_LIST()
 };
 
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 4228713b19..dd9ba973f7 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -42,8 +42,10 @@ static inline void unset_feature(CPUARMState *env, int 
feature)
 #ifndef CONFIG_USER_ONLY
 static uint64_t a57_a53_l2ctlr_read(CPUARMState *env, const ARMCPRegInfo *ri)
 {
-/* Number of processors is in [25:24]; otherwise we RAZ */
-return (smp_cpus - 1) << 24;
+ARMCPU *cpu = arm_env_get_cpu(env);
+
+/* Number of cores is in [25:24]; otherwise we RAZ */
+return (cpu->core_count - 1) << 24;
 }
 #endif
 
-- 
2.14.1




Re: [Qemu-devel] [PATCH v2 03/15] qio: introduce qio_channel_add_watch_{full|source}

2018-03-02 Thread Paolo Bonzini
On 02/03/2018 16:44, Daniel P. Berrangé wrote:
>> Just a small thing, this is a bit inconsistent with the rest of the
>> GSource API, where the g_source_attach is usually left to the caller
>> when a function returns GSource *.
> The APIs which return a GSource in glib typically don't even set the
> callback function - we already cover that scenario with the
> qio_channel_create_watch APIs.
> 
> GLib doesn't typically have APIs which return a GSource after the
> mix of creating the watch, setting callback & attaching to context.

True, on the other hand it's annoying for qio_channel_create_watch
because of the function pointer case.  So I suggested a mix of creating
the watch and setting the callback.

Having a function that takes a GMainContext and returns a tag is fine, too.

Paolo

> They all just return the watch ID value.
> 
> So I think this proposal is ok as it is as there's no real precedence.
> 
> Alternatively we could simply do without this API entirely. It is
> trivial enough for the code that needs a GSource to get iuse the
> normal qio_channel_add_watch|watch_full APIs, and then lookup the
> GSource themselves - only one extra line of code in the callers.




[Qemu-devel] [PATCH 2/2] q35: change default NIC to e1000e

2018-03-02 Thread Paolo Bonzini
The e1000 NIC is getting old and is not a very good default for a
PCIe machine type.  Change it to e1000e, which should be supported
by a good number of guests.

Signed-off-by: Paolo Bonzini 
---
 hw/i386/pc.c | 5 +++--
 hw/i386/pc_piix.c| 2 +-
 hw/i386/pc_q35.c | 2 +-
 include/hw/i386/pc.h | 2 +-
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 2f7746c859..1398ac9b68 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1619,7 +1619,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 }
 }
 
-void pc_nic_init(ISABus *isa_bus, PCIBus *pci_bus)
+void pc_nic_init(ISABus *isa_bus, PCIBus *pci_bus, const char *default_model)
 {
 int i;
 
@@ -1630,7 +1630,8 @@ void pc_nic_init(ISABus *isa_bus, PCIBus *pci_bus)
 if (!pci_bus || (nd->model && strcmp(nd->model, "ne2k_isa") == 0)) {
 pc_init_ne2k_isa(isa_bus, nd);
 } else {
-pci_nic_init_nofail(nd, pci_bus, "e1000", NULL);
+const char *model = nd->model ? nd->model : default_model;
+pci_nic_init_nofail(nd, pci_bus, model, NULL);
 }
 }
 rom_reset_order_override();
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 8658bcba63..309b052ed1 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -240,7 +240,7 @@ static void pc_init1(MachineState *machine,
 pc_basic_device_init(isa_bus, pcms->gsi, _state, true,
  (pcms->vmport != ON_OFF_AUTO_ON), pcms->pit, 0x4);
 
-pc_nic_init(isa_bus, pci_bus);
+pc_nic_init(isa_bus, pci_bus, "e1000");
 
 ide_drive_get(hd, ARRAY_SIZE(hd));
 if (pcmc->pci_enabled) {
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 0c0bc48137..764179af08 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -272,7 +272,7 @@ static void pc_q35_init(MachineState *machine)
 
 /* the rest devices to which pci devfn is automatically assigned */
 pc_vga_init(isa_bus, host_bus);
-pc_nic_init(isa_bus, host_bus);
+pc_nic_init(isa_bus, host_bus, "e1000e");
 
 if (pcms->acpi_nvdimm_state.is_enabled) {
 nvdimm_init_acpi_state(>acpi_nvdimm_state, system_io,
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index bb49165fe0..25d71f3bb5 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -248,7 +248,7 @@ void pc_init_ne2k_isa(ISABus *bus, NICInfo *nd);
 void pc_cmos_init(PCMachineState *pcms,
   BusState *ide0, BusState *ide1,
   ISADevice *s);
-void pc_nic_init(ISABus *isa_bus, PCIBus *pci_bus);
+void pc_nic_init(ISABus *isa_bus, PCIBus *pci_bus, const char *default_model);
 void pc_pci_device_init(PCIBus *pci_bus);
 
 typedef void (*cpu_set_smm_t)(int smm, void *arg);
-- 
2.14.3




Re: [Qemu-devel] [PATCH v1 1/1] target/arm: Fix the A53 L2CTLR typo

2018-03-02 Thread Alistair Francis
On Fri, Mar 2, 2018 at 2:35 AM, Peter Maydell  wrote:
> On 2 March 2018 at 10:29, Peter Maydell  wrote:
>> On 2 March 2018 at 04:34, Alistair Francis  wrote:
>>> target/arm: Report the number of cores in the cluster
>>>
>>> Previously we assumed that we only has a single cluster, which meant we
>>> could get away with reporting smp_cpus to the guest. There are cases
>>> where we have two clusters (Xilinx's ZynqMP is a good example) so
>>> reporting the number of smp_cpus is incorrect. Instead count the cores
>>> in the cluster.
>
>> This seems a bit ad-hoc (it will give the wrong answer if we have
>> two clusters both of the same kind of CPU, for instance).
>> Maybe it would be better to have a "cluster-size" property on
>> the CPU (with the default being number of cores in whole system) ?
>
> ...though I think "cluster size" isn't quite the right name --
> if you have a big.LITTLE cluster with 2xA57 and 2xA53, there are
> 4 cores in the cluster but I think reading the TRM that the cores
> will report 2 in the L2CTLR.

Hmmm... I would have thought cluster size is correct enough. The only
other option I can think of is "processor size" or "core size"?

Alistair

>
> thanks
> -- PMM



Re: [Qemu-devel] [PULL v3 00/30] QAPI patches for 2018-03-01

2018-03-02 Thread Eric Blake

On 03/02/2018 10:55 AM, Peter Maydell wrote:

On 2 March 2018 at 15:31, Eric Blake  wrote:

The following changes since commit 2e7b766594e17f786a6b2e5be690bc5b43ce6036:

   Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2018-03-01' into 
staging (2018-03-02 12:39:13 +)

are available in the Git repository at:

   git://repo.or.cz/qemu/ericb.git tags/pull-qapi-2018-03-01-v3

for you to fetch changes up to cfe6a7fc6da20349ef62966c437f18ed6c49fcd5:

   qapi: Don't create useless directory qapi-generated (2018-03-02 09:01:40 
-0600)

v3: (attempt to) fix warnings about empty .o files on OSX toolchain [Peter]
(sending just the changed patch)


qapi patches for 2018-03-01

- Markus Armbruster: Modularize generated QAPI code



As I suspected, this isn't sufficient to silence the warnings.


So 'static char' wasn't enough to create an export table, and I have to 
actually export something (while still ensuring it does not collide). 
Okay, I'll work up a v4 along those lines.


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



Re: [Qemu-devel] [Qemu-block] [RFC PATCH 0/2] Increase usability of external snapshots

2018-03-02 Thread Roman Kagan
On Tue, Feb 27, 2018 at 12:56:49PM +0100, Richard Palethorpe wrote:
> Following on from the discussion about creating savevm/loadvm QMP
> equivalents. I decided to take the advice given that we should use external
> snapshots. However reverting to a snapshot currently requires QEMU to be
> restarted with "-incoming".  Restarting QEMU requires a fair bit of
> book keeping to be done by the management application and may take
> measurably more time.

AFAICT "-incoming" is not the only reason for starting QEMU anew.  The
block devices will need to be pointed at different nodes in the backing
chains.  Moreover the snapshot you're reverting to may have been taken
at a point where the VM had different configuration than it has now.

So the management application will need to do a lot of bookkeeping stuff
anyway, and it'll probably have harder time applying all of the
configuration changes to a live QEMU instance.

Is the cost of killing the old QEMU process and starting a new one big
enough to be worth all the hassle?

Thanks,
Roman.



[Qemu-devel] [PATCH] ide: fix invalid TRIM range abortion for macio

2018-03-02 Thread Anton Nefedov
commit 947858b0 "ide: abort TRIM operation for invalid range"
is incorrect for macio; just ide_dma_error() without doing a callback
is not enough for that errorpath.

Instead, pass -EINVAL to the callback and handle it there
(see related motivation for read/write in 58ac32113).

It will however catch possible EINVAL from the block layer too.

Signed-off-by: Anton Nefedov 
---
 hw/ide/core.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/hw/ide/core.c b/hw/ide/core.c
index 257b429..54510d4 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -402,7 +402,6 @@ typedef struct TrimAIOCB {
 QEMUIOVector *qiov;
 BlockAIOCB *aiocb;
 int i, j;
-bool is_invalid;
 } TrimAIOCB;
 
 static void trim_aio_cancel(BlockAIOCB *acb)
@@ -430,11 +429,8 @@ static void ide_trim_bh_cb(void *opaque)
 {
 TrimAIOCB *iocb = opaque;
 
-if (iocb->is_invalid) {
-ide_dma_error(iocb->s);
-} else {
-iocb->common.cb(iocb->common.opaque, iocb->ret);
-}
+iocb->common.cb(iocb->common.opaque, iocb->ret);
+
 qemu_bh_delete(iocb->bh);
 iocb->bh = NULL;
 qemu_aio_unref(iocb);
@@ -462,7 +458,7 @@ static void ide_issue_trim_cb(void *opaque, int ret)
 }
 
 if (!ide_sect_range_ok(s, sector, count)) {
-iocb->is_invalid = true;
+iocb->ret = -EINVAL;
 goto done;
 }
 
@@ -502,7 +498,6 @@ BlockAIOCB *ide_issue_trim(
 iocb->qiov = qiov;
 iocb->i = -1;
 iocb->j = 0;
-iocb->is_invalid = false;
 ide_issue_trim_cb(iocb, 0);
 return >common;
 }
@@ -848,6 +843,12 @@ static void ide_dma_cb(void *opaque, int ret)
 if (ret == -ECANCELED) {
 return;
 }
+
+if (ret == -EINVAL) {
+ide_dma_error(s);
+return;
+}
+
 if (ret < 0) {
 if (ide_handle_rw_error(s, -ret, ide_dma_cmd_to_retry(s->dma_cmd))) {
 s->bus->dma->aiocb = NULL;
-- 
2.7.4




[Qemu-devel] [PATCH v3] ppc4xx: Add device models found in PPC440 core SoCs

2018-03-02 Thread BALATON Zoltan
These devices are found in newer SoCs based on 440 core e.g. the 460EX
(http://www.embeddeddeveloper.com/assets/processors/amcc/datasheets/
PP460EX_DS2063.pdf)

Signed-off-by: BALATON Zoltan 
Signed-off-by: David Gibson 
---
v3: Fixed warning from older gcc about variable used uninitialised

 hw/ppc/ppc440.h|   26 +
 hw/ppc/ppc440_uc.c | 1162 
 include/hw/pci/pcie_host.h |2 +-
 3 files changed, 1189 insertions(+), 1 deletion(-)
 create mode 100644 hw/ppc/ppc440.h
 create mode 100644 hw/ppc/ppc440_uc.c

diff --git a/hw/ppc/ppc440.h b/hw/ppc/ppc440.h
new file mode 100644
index 000..ad27db1
--- /dev/null
+++ b/hw/ppc/ppc440.h
@@ -0,0 +1,26 @@
+/*
+ * QEMU PowerPC 440 shared definitions
+ *
+ * Copyright (c) 2012 François Revol
+ * Copyright (c) 2016-2018 BALATON Zoltan
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ *
+ */
+
+#ifndef PPC440_H
+#define PPC440_H
+
+#include "hw/ppc/ppc.h"
+
+void ppc4xx_l2sram_init(CPUPPCState *env);
+void ppc4xx_cpr_init(CPUPPCState *env);
+void ppc4xx_sdr_init(CPUPPCState *env);
+void ppc440_sdram_init(CPUPPCState *env, int nbanks,
+   MemoryRegion *ram_memories,
+   hwaddr *ram_bases, hwaddr *ram_sizes,
+   int do_init);
+void ppc4xx_ahb_init(CPUPPCState *env);
+void ppc460ex_pcie_init(CPUPPCState *env);
+
+#endif /* PPC440_H */
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
new file mode 100644
index 000..976ab2b
--- /dev/null
+++ b/hw/ppc/ppc440_uc.c
@@ -0,0 +1,1162 @@
+/*
+ * QEMU PowerPC 440 embedded processors emulation
+ *
+ * Copyright (c) 2012 François Revol
+ * Copyright (c) 2016-2018 BALATON Zoltan
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/cutils.h"
+#include "qemu/error-report.h"
+#include "qapi/error.h"
+#include "cpu.h"
+#include "hw/hw.h"
+#include "exec/address-spaces.h"
+#include "exec/memory.h"
+#include "hw/ppc/ppc.h"
+#include "hw/pci/pci.h"
+#include "sysemu/block-backend.h"
+#include "hw/ppc/ppc440.h"
+
+/*/
+/* L2 Cache as SRAM */
+/* FIXME:fix names */
+enum {
+DCR_L2CACHE_BASE  = 0x30,
+DCR_L2CACHE_CFG   = DCR_L2CACHE_BASE,
+DCR_L2CACHE_CMD,
+DCR_L2CACHE_ADDR,
+DCR_L2CACHE_DATA,
+DCR_L2CACHE_STAT,
+DCR_L2CACHE_CVER,
+DCR_L2CACHE_SNP0,
+DCR_L2CACHE_SNP1,
+DCR_L2CACHE_END   = DCR_L2CACHE_SNP1,
+};
+
+/* base is 460ex-specific, cf. U-Boot, ppc4xx-isram.h */
+enum {
+DCR_ISRAM0_BASE   = 0x20,
+DCR_ISRAM0_SB0CR  = DCR_ISRAM0_BASE,
+DCR_ISRAM0_SB1CR,
+DCR_ISRAM0_SB2CR,
+DCR_ISRAM0_SB3CR,
+DCR_ISRAM0_BEAR,
+DCR_ISRAM0_BESR0,
+DCR_ISRAM0_BESR1,
+DCR_ISRAM0_PMEG,
+DCR_ISRAM0_CID,
+DCR_ISRAM0_REVID,
+DCR_ISRAM0_DPC,
+DCR_ISRAM0_END= DCR_ISRAM0_DPC
+};
+
+enum {
+DCR_ISRAM1_BASE   = 0xb0,
+DCR_ISRAM1_SB0CR  = DCR_ISRAM1_BASE,
+/* single bank */
+DCR_ISRAM1_BEAR   = DCR_ISRAM1_BASE + 0x04,
+DCR_ISRAM1_BESR0,
+DCR_ISRAM1_BESR1,
+DCR_ISRAM1_PMEG,
+DCR_ISRAM1_CID,
+DCR_ISRAM1_REVID,
+DCR_ISRAM1_DPC,
+DCR_ISRAM1_END= DCR_ISRAM1_DPC
+};
+
+typedef struct ppc4xx_l2sram_t {
+MemoryRegion bank[4];
+uint32_t l2cache[8];
+uint32_t isram0[11];
+} ppc4xx_l2sram_t;
+
+#ifdef MAP_L2SRAM
+static void l2sram_update_mappings(ppc4xx_l2sram_t *l2sram,
+   uint32_t isarc, uint32_t isacntl,
+   uint32_t dsarc, uint32_t dsacntl)
+{
+if (l2sram->isarc != isarc ||
+(l2sram->isacntl & 0x8000) != (isacntl & 0x8000)) {
+if (l2sram->isacntl & 0x8000) {
+/* Unmap previously assigned memory region */
+memory_region_del_subregion(get_system_memory(),
+>isarc_ram);
+}
+if (isacntl & 0x8000) {
+/* Map new instruction memory region */
+memory_region_add_subregion(get_system_memory(), isarc,
+>isarc_ram);
+}
+}
+if (l2sram->dsarc != dsarc ||
+(l2sram->dsacntl & 0x8000) != (dsacntl & 0x8000)) {
+if (l2sram->dsacntl & 0x8000) {
+/* Beware not to unmap the region we just mapped */
+if (!(isacntl & 0x8000) || l2sram->dsarc != isarc) {
+/* Unmap previously assigned memory region */
+memory_region_del_subregion(get_system_memory(),
+>dsarc_ram);
+}
+}
+if (dsacntl & 0x8000) {
+/* Beware not to remap the region we just mapped */
+if (!(isacntl & 0x8000) || dsarc != isarc) {
+/* Map new 

Re: [Qemu-devel] [PATCH 0/3] vfio/pci: ioeventfd support

2018-03-02 Thread Alex Williamson
On Fri, 2 Mar 2018 07:08:51 +
"Tian, Kevin"  wrote:

> > From: Alex Williamson
> > Sent: Thursday, March 1, 2018 4:15 AM
> > 
> > A vfio ioeventfd will perform the pre-specified device write on
> > triggering of an eventfd.  When coupled with KVM ioeventfds, this
> > feature allows a VM to trap a device page for virtualization, while
> > also registering targeted ioeventfds to maintain performance of high
> > frequency register writes within the trapped range.  Much like the
> > existing interrupt eventfd/irqfd coupling, such writes can be handled
> > entirely in the host kernel.
> > 
> > The new VFIO device ioctl may be supported by any vfio bus driver,
> > including mdev drivers, but the implementation here only enables
> > vfio-pci.  This is intended as an acceleration path, bus drivers
> > may choose which regions to support and userspace should always
> > intend to fall back to non-accelerated handling when unavailable.
> >   
> 
> it's a nice feature! A curious question. Is it possible for mdev driver
> to directly create ioeventfd on specified offset? Currently ioeventfd
> requires quirks in Qemu, which must know the device detail to
> create ioeventfd and then connect vfio and kvm together. However
> mdev instance is more software defined thus I'm not sure whether 
> asking Qemu to catch up quirk with underlying software logic could
> be overwhelmed. Also in case of vendor driver emulating mdev
> with same DID/VID as a real device, it might be difficult for Qemu
> to figure out whether a vfio device is a real one or mdev one to
> apply a mdev specific quirk. On the other hand, since vendor
> driver knows all the logic constructing mdev, it would be more
> convenient allowing vendor driver to directly create/destroy
> ioeventfd on its demand?

Are file descriptors the right interface between kernel components if
userspace is not involved in connecting them?  Seems like not.  vfio is
designed to be independent of KVM with the necessary interactions
between them orchestrated by userspace.  KVMGT is about the only
exception to that and TBH I'm not thrilled about extending that
further.  Thanks,

Alex



Re: [Qemu-devel] [PATCH V7 2/4] tests/migration: Convert the boot block compilation script into Makefile

2018-03-02 Thread Wei Huang


On 03/02/2018 09:25 AM, Laurent Vivier wrote:
> On 28/02/2018 19:02, Wei Huang wrote:
>> The x86 boot block header currently is generated with a shell script.
>> To better support other CPUs (e.g. aarch64), we convert the script
>> into Makefile. This allows us to 1) support cross-compilation easily,
>> and 2) avoid creating a script file for every architecture.
>>
>> Signed-off-by: Wei Huang 
>> Reviewed-by: Andrew Jones 
>> ---
>>  tests/migration/Makefile | 36 
>> 
>>  tests/migration/rebuild-x86-bootblock.sh | 33 -
>>  tests/migration/x86-a-b-bootblock.h  |  2 +-
>>  tests/migration/x86-a-b-bootblock.s  |  5 ++---
>>  4 files changed, 39 insertions(+), 37 deletions(-)
>>  create mode 100644 tests/migration/Makefile
>>  delete mode 100755 tests/migration/rebuild-x86-bootblock.sh
>>
>> diff --git a/tests/migration/Makefile b/tests/migration/Makefile
>> new file mode 100644
>> index 00..8fbedaa8b8
>> --- /dev/null
>> +++ b/tests/migration/Makefile
>> @@ -0,0 +1,36 @@
>> +#
>> +# Copyright (c) 2016-2018 Red Hat, Inc. and/or its affiliates
>> +#
>> +# Authors:
>> +#   Dave Gilbert 
>> +#
>> +# This work is licensed under the terms of the GNU GPL, version 2 or later.
>> +# See the COPYING file in the top-level directory.
>> +#
>> +export __note
>> +override define __note
>> +/* This file is automatically generated from
>> + * tests/migration/$<, edit that and then run
>> + * "make $@" inside tests/migration to update,
>> + * and then remember to send both in your patch submission.
>> + */
>> +endef
>> +
>> +all: x86-a-b-bootblock.h
>> +# Dummy command so that make thinks it has done something
>> +@true
>> +
>> +SRC_PATH=../..
>> +include $(SRC_PATH)/rules.mak
> 
> does it work in not in-tree build?

Yes, I tried it with a out-of-tree build and it worked. More
specifically, because .h file (e.g. x86-a-b-bootblock.h) is provided,
this Makefile is disjoint from the main build system and it has to be
invoked explicitly. So it won't be affected by out-of-tree build.

> 
>> +
>> +x86_64_cross_prefix := $(call find-cross-prefix,x86_64)
>> +
>> +x86-a-b-bootblock.h: x86-a-b-bootblock.s
>> +$(x86_64_cross_prefix)as --32 -march=i486 $< -o x86.o
>> +$(x86_64_cross_prefix)objcopy -O binary x86.o x86.boot
>> +dd if=x86.boot of=x86.bootsect bs=256 count=2 skip=124
>> +echo "$$__note" > $@
>> +xxd -i x86.bootsect | sed -e 's/.*int.*//' >> $@
> 
> To be really in the spirit of a makefile, you should have a rule by target:
> 
> x86.o: x86-a-b-bootblock.s
>   $(x86_64_cross_prefix)as --32 -march=i486 $< -o x86.o
> 
> x86.boot: x86.o
>   $(x86_64_cross_prefix)objcopy -O binary x86.o x86.boot
> 
> x86.bootsect: x86.boot
>   dd if=x86.boot of=x86.bootsect bs=256 count=2 skip=124
> 
> x86-a-b-bootblock.h: x86.bootsect
>   echo "$$__note" > header.tmp
>   xxd -i x86.bootsect | sed -e 's/.*int.*//' >> header.tmp
>   mv header.tmp $@
> 

It is cleaner, I agree. But it will make the Makefile quite bulky
(remember that we have to do the same for aarch64 and others).

> Thanks,
> Laurent
> 



[Qemu-devel] [PATCH v1 0/2] Add a property to set the ARM CPU core count

2018-03-02 Thread Alistair Francis

Add an ARM CPU property which allows us to set the ARM CPU core count.



Alistair Francis (2):
  target/arm: Add a cluster size property
  hw/arm: Set the core count for Xilinx's ZynqMP

 target/arm/cpu.h |  5 +
 hw/arm/xlnx-zynqmp.c |  2 ++
 target/arm/cpu.c |  1 +
 target/arm/cpu64.c   | 11 +--
 4 files changed, 17 insertions(+), 2 deletions(-)

-- 
2.14.1




[Qemu-devel] [PATCH v1 1/2] target/arm: Add a cluster size property

2018-03-02 Thread Alistair Francis
The cortex A53 TRM specifices that bits 24 and 25 of the L2CTLR register
specify the number of cores present and not the number of processors. To
report this correctly on machines with multiple CPU clusters (ARM's
big.LITTLE or Xilinx's ZynqMP) we need to allow the machine to overwrite
this value. To do this let's add an optional property.

Signed-off-by: Alistair Francis 
---

 target/arm/cpu.h   |  5 +
 target/arm/cpu.c   |  1 +
 target/arm/cpu64.c | 11 +--
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 8dd6b788df..3fa8fdad21 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -745,6 +745,11 @@ struct ARMCPU {
 /* Uniprocessor system with MP extensions */
 bool mp_is_up;
 
+/* Specify the number of cores in this CPU cluster. Used for the L2CTLR
+ * register.
+ */
+int32_t core_count;
+
 /* The instance init functions for implementation-specific subclasses
  * set these fields to specify the implementation-dependent values of
  * various constant registers and reset values of non-constant
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 6b77aaa445..7a17ba1418 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1765,6 +1765,7 @@ static Property arm_cpu_properties[] = {
 DEFINE_PROP_UINT64("mp-affinity", ARMCPU,
 mp_affinity, ARM64_AFFINITY_INVALID),
 DEFINE_PROP_INT32("node-id", ARMCPU, node_id, CPU_UNSET_NUMA_NODE_ID),
+DEFINE_PROP_INT32("core-count", ARMCPU, core_count, -1),
 DEFINE_PROP_END_OF_LIST()
 };
 
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 4228713b19..5e5ae44aeb 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -42,8 +42,15 @@ static inline void unset_feature(CPUARMState *env, int 
feature)
 #ifndef CONFIG_USER_ONLY
 static uint64_t a57_a53_l2ctlr_read(CPUARMState *env, const ARMCPRegInfo *ri)
 {
-/* Number of processors is in [25:24]; otherwise we RAZ */
-return (smp_cpus - 1) << 24;
+ARMCPU *cpu = arm_env_get_cpu(env);
+
+/* Number of cores is in [25:24]; otherwise we RAZ */
+if (cpu->core_count == -1) {
+/* No core_count specified, default to smp_cpus. */
+return (smp_cpus - 1) << 24;
+} else {
+return (cpu->core_count - 1) << 24;
+}
 }
 #endif
 
-- 
2.14.1




[Qemu-devel] [PATCH v1 2/2] hw/arm: Set the core count for Xilinx's ZynqMP

2018-03-02 Thread Alistair Francis
Set the ARM CPU core count property for the A53's attached to the Xilnx
ZynqMP machine.

Signed-off-by: Alistair Francis 
---

 hw/arm/xlnx-zynqmp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index 69227fd4c9..465796e97c 100644
--- a/hw/arm/xlnx-zynqmp.c
+++ b/hw/arm/xlnx-zynqmp.c
@@ -282,6 +282,8 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
**errp)
  s->virt, "has_el2", NULL);
 object_property_set_int(OBJECT(>apu_cpu[i]), GIC_BASE_ADDR,
 "reset-cbar", _abort);
+object_property_set_int(OBJECT(>apu_cpu[i]), num_apus,
+"core-count", _abort);
 object_property_set_bool(OBJECT(>apu_cpu[i]), true, "realized",
  );
 if (err) {
-- 
2.14.1




Re: [Qemu-devel] [PATCH] net: fix misaligned member access

2018-03-02 Thread Peter Maydell
On 9 February 2018 at 19:03, Marc-André Lureau
 wrote:
> Fixes the following ASAN warnings:
>
> /home/elmarco/src/qemu/hw/net/net_tx_pkt.c:201:27: runtime error: member 
> access within misaligned address 0x63128846 for type 'struct ip_header', 
> which requires 4 byte alignment
> 0x63128846: note: pointer points here
>  01 00 00 00 45 00  01 a9 01 00 00 00 40 11  78 45 00 00 00 00 ff ff  ff ff 
> 00 00 00 00 00 00  00 00
>  ^
> /home/elmarco/src/qemu/hw/net/net_tx_pkt.c:208:63: runtime error: member 
> access within misaligned address 0x63128846 for type 'struct ip_header', 
> which requires 4 byte alignment
> 0x63128846: note: pointer points here
>  01 00 00 00 45 00  01 a9 01 00 00 00 40 11  78 45 00 00 00 00 ff ff  ff ff 
> 00 00 00 00 00 00  00 00
>  ^
> /home/elmarco/src/qemu/hw/net/net_tx_pkt.c:210:13: runtime error: member 
> access within misaligned address 0x63128846 for type 'struct ip_header', 
> which requires 4 byte alignment
> 0x63128846: note: pointer points here
>  01 00 00 00 45 00  01 a9 01 00 00 00 40 11  78 45 00 00 00 00 ff ff  ff ff 
> 00 00 00 00 00 00  00 00
>
> Signed-off-by: Marc-André Lureau 
> ---
>  include/net/eth.h   | 4 +++-
>  hw/net/net_tx_pkt.c | 2 +-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/eth.h b/include/net/eth.h
> index 09054a506d..e6dc8a7ba0 100644
> --- a/include/net/eth.h
> +++ b/include/net/eth.h
> @@ -194,7 +194,9 @@ struct tcp_hdr {
>  #define PKT_GET_IP_HDR(p) \
>  ((struct ip_header *)(((uint8_t *)(p)) + eth_get_l2_hdr_length(p)))
>  #define IP_HDR_GET_LEN(p) \
> -struct ip_header *)(p))->ip_ver_len & 0x0F) << 2)
> +((ldub_p(p + offsetof(struct ip_header, ip_ver_len)) & 0x0F) << 2)
> +#define IP_HDR_GET_P(p)   \
> +(ldub_p(p + offsetof(struct ip_header, ip_p)))
>  #define PKT_GET_IP_HDR_LEN(p) \
>  (IP_HDR_GET_LEN(PKT_GET_IP_HDR(p)))
>  #define PKT_GET_IP6_HDR(p)\
> diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
> index e29c881bc2..162f802dd7 100644
> --- a/hw/net/net_tx_pkt.c
> +++ b/hw/net/net_tx_pkt.c
> @@ -205,7 +205,7 @@ static bool net_tx_pkt_parse_headers(struct NetTxPkt *pkt)
>  return false;
>  }
>
> -pkt->l4proto = ((struct ip_header *) l3_hdr->iov_base)->ip_p;
> +pkt->l4proto = IP_HDR_GET_P(l3_hdr->iov_base);
>
>  if (IP_HDR_GET_LEN(l3_hdr->iov_base) != sizeof(struct ip_header)) {
>  /* copy optional IPv4 header data if any*/
> --
> 2.16.1.73.g5832b7e9f2

Reviewed-by: Peter Maydell 

and I'm going to apply this to master, because I'm fed up of the warnings
in my build system logs.

It looks like all these macros need to be fixed, though, not just these two.

thanks
-- PMM



Re: [Qemu-devel] [PATCH v1 1/2] target/arm: Add a cluster size property

2018-03-02 Thread Peter Maydell
On 2 March 2018 at 17:06, Alistair Francis  wrote:

Subject should say "core count" rather than "cluster size" ?

> The cortex A53 TRM specifices that bits 24 and 25 of the L2CTLR register

"specifies"

> specify the number of cores present and not the number of processors. To

"the number of cores in the processor, not the total number of cores
in the system".

> report this correctly on machines with multiple CPU clusters (ARM's
> big.LITTLE or Xilinx's ZynqMP) we need to allow the machine to overwrite
> this value. To do this let's add an optional property.
>
> Signed-off-by: Alistair Francis 
> ---
>
>  target/arm/cpu.h   |  5 +
>  target/arm/cpu.c   |  1 +
>  target/arm/cpu64.c | 11 +--
>  3 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 8dd6b788df..3fa8fdad21 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -745,6 +745,11 @@ struct ARMCPU {
>  /* Uniprocessor system with MP extensions */
>  bool mp_is_up;
>
> +/* Specify the number of cores in this CPU cluster. Used for the L2CTLR
> + * register.
> + */
> +int32_t core_count;
> +
>  /* The instance init functions for implementation-specific subclasses
>   * set these fields to specify the implementation-dependent values of
>   * various constant registers and reset values of non-constant
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index 6b77aaa445..7a17ba1418 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -1765,6 +1765,7 @@ static Property arm_cpu_properties[] = {
>  DEFINE_PROP_UINT64("mp-affinity", ARMCPU,
>  mp_affinity, ARM64_AFFINITY_INVALID),
>  DEFINE_PROP_INT32("node-id", ARMCPU, node_id, CPU_UNSET_NUMA_NODE_ID),
> +DEFINE_PROP_INT32("core-count", ARMCPU, core_count, -1),
>  DEFINE_PROP_END_OF_LIST()
>  };
>
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 4228713b19..5e5ae44aeb 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -42,8 +42,15 @@ static inline void unset_feature(CPUARMState *env, int 
> feature)
>  #ifndef CONFIG_USER_ONLY
>  static uint64_t a57_a53_l2ctlr_read(CPUARMState *env, const ARMCPRegInfo *ri)
>  {
> -/* Number of processors is in [25:24]; otherwise we RAZ */
> -return (smp_cpus - 1) << 24;
> +ARMCPU *cpu = arm_env_get_cpu(env);
> +
> +/* Number of cores is in [25:24]; otherwise we RAZ */
> +if (cpu->core_count == -1) {
> +/* No core_count specified, default to smp_cpus. */
> +return (smp_cpus - 1) << 24;
> +} else {
> +return (cpu->core_count - 1) << 24;
> +}
>  }
>  #endif

I think having arm_cpu_realizefn do
if (cpu->core_count == -1) {
cpu->core_count = smp_cpus;
}

would be neater than doing that check when the register is read.

thanks
-- PMM



Re: [Qemu-devel] [PATCH 1/2] net: add e1000e model to the "simple" -net/-nic options

2018-03-02 Thread Paolo Bonzini
On 02/03/2018 18:19, Thomas Huth wrote:
> On 02.03.2018 16:51, Paolo Bonzini wrote:
>> Signed-off-by: Paolo Bonzini 
>> ---
>>  hw/pci/pci.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
>> index e006b6ac71..af3c85a46f 100644
>> --- a/hw/pci/pci.c
>> +++ b/hw/pci/pci.c
>> @@ -1822,6 +1822,7 @@ static const char * const pci_nic_models[] = {
>>  "i82559er",
>>  "rtl8139",
>>  "e1000",
>> +"e1000e",
>>  "pcnet",
>>  "virtio",
>>  "sungem",
>> @@ -1835,6 +1836,7 @@ static const char * const pci_nic_names[] = {
>>  "i82559er",
>>  "rtl8139",
>>  "e1000",
>> +"e1000e",
>>  "pcnet",
>>  "virtio-net-pci",
>>  "sungem",
> 
> I think it would be better and more consisten to finally fix this mess
> and automatically allow all devices in the category
> DEVICE_CATEGORY_NETWORK that are derived from TYPE_PCI_DEVICE, instead
> of manually maintaining this list here...?

Yeah, that would make sense too (virtio would be special cased).  Thanks!

Paolo



Re: [Qemu-devel] [PATCH v1 1/2] target/arm: Add a cluster size property

2018-03-02 Thread Peter Maydell
On 2 March 2018 at 17:35, Alistair Francis  wrote:
> Ok will fix. I'll send a V2 out straight away, as today is my last day
> and it'd be great if I could get this done.

Sure -- if there are any further nits in v2 I'll just fix them
up when I put it into target-arm.next.

-- PMM



[Qemu-devel] [PATCH v2 2/2] hw/arm: Set the core count for Xilinx's ZynqMP

2018-03-02 Thread Alistair Francis
Set the ARM CPU core count property for the A53's attached to the Xilnx
ZynqMP machine.

Signed-off-by: Alistair Francis 
Reviewed-by: Peter Maydell 
---

 hw/arm/xlnx-zynqmp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index 69227fd4c9..465796e97c 100644
--- a/hw/arm/xlnx-zynqmp.c
+++ b/hw/arm/xlnx-zynqmp.c
@@ -282,6 +282,8 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
**errp)
  s->virt, "has_el2", NULL);
 object_property_set_int(OBJECT(>apu_cpu[i]), GIC_BASE_ADDR,
 "reset-cbar", _abort);
+object_property_set_int(OBJECT(>apu_cpu[i]), num_apus,
+"core-count", _abort);
 object_property_set_bool(OBJECT(>apu_cpu[i]), true, "realized",
  );
 if (err) {
-- 
2.14.1




Re: [Qemu-devel] [Qemu-block] [PATCH] virtio-blk: notify guest directly

2018-03-02 Thread Sergio Lopez
On Fri, Mar 02, 2018 at 01:38:52PM +, Stefan Hajnoczi wrote:
> On Tue, Dec 19, 2017 at 1:33 PM, sochin.jiang  wrote:
> >  Till now, we've already notify guest as a batch mostly, an
> >  extra BH won't decrease guest interrupts much, but cause a
> >  significant notification loss. Generally, we could have 15%
> >  or so performance lost in single queue IO models, as I tested.
> 
> Recent performance testing has shown that virtio-blk can underperform
> virtio-scsi due to the extra latency added by the BH.
> 
> The virtqueue EVENT_IDX feature mitigates interrupts when the guest
> interrupt handler has not had a chance to run yet.  Therefore, virtio
> already offers one level of interrupt mitigation and the BH adds
> additional latency on top.

FWIW, I'm writing a patch that disables the BH (notifying after each completion
instead) when EVENT_IDX is present. I'll send both the patch and some fio
numbers next week.

Sergio.



Re: [Qemu-devel] [PATCH v2 3/5] target/i386: Add support for CPUID_8000_001E for AMD

2018-03-02 Thread Moger, Babu


> -Original Message-
> From: Radim Krčmář [mailto:rkrc...@redhat.com]
> Sent: Thursday, March 1, 2018 1:57 PM
> To: Moger, Babu 
> Cc: pbonz...@redhat.com; r...@twiddle.net; ehabk...@redhat.com;
> mtosa...@redhat.com; qemu-devel@nongnu.org; k...@vger.kernel.org;
> p...@polepetko.eu; Hook, Gary 
> Subject: Re: [PATCH v2 3/5] target/i386: Add support for CPUID_8000_001E
> for AMD
> 
> 2018-02-28 22:18+, Moger, Babu:
> > > -Original Message-
> > > From: Radim Krčmář [mailto:rkrc...@redhat.com]
> > > Sent: Wednesday, February 28, 2018 12:24 PM
> > > To: Moger, Babu 
> > > Cc: pbonz...@redhat.com; r...@twiddle.net; ehabk...@redhat.com;
> > > mtosa...@redhat.com; qemu-devel@nongnu.org; k...@vger.kernel.org;
> > > p...@polepetko.eu; Hook, Gary 
> > > Subject: Re: [PATCH v2 3/5] target/i386: Add support for
> CPUID_8000_001E
> > > for AMD
> > >
> > > 2018-02-23 21:30-0500, Babu Moger:
> > > > From: Stanislav Lanci 
> > > >
> > > > Populate threads/core_id/apic_ids/socket_id when
> CPUID_EXT3_TOPOEXT
> > > > feature is supported. This is required to support hyperthreading
> > > > feature on AMD CPUS. These are supported via CPUID_8000_001E
> > > extended
> > > > functions.
> > > >
> > > > Signed-off-by: Stanislav Lanci 
> > > > Signed-off-by: Babu Moger 
> > > > ---
> > > >  target/i386/cpu.c | 8 
> > > >  1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > > index a5a480e..191e850 100644
> > > > --- a/target/i386/cpu.c
> > > > +++ b/target/i386/cpu.c
> > > > @@ -3666,6 +3666,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> > > uint32_t index, uint32_t count,
> > > >  *edx = 0;
> > > >  }
> > > >  break;
> > > > +case 0x801E:
> > > > +if (env->features[FEAT_8000_0001_ECX] &
> CPUID_EXT3_TOPOEXT) {
> > > > +*eax = cpu->apic_id;
> > > > +*ebx = (cs->nr_threads - 1) << 8 | cpu->core_id;
> > >
> > > Do we somewhere assert that AMD cannot have cpu->core_id > 255?
> > > (qemu does allow weird configurations.)
> >
> > I don't see specific assert on core_id.   But, I see that qemu does not 
> > allow
> nr_cores more than 255.
> > Also I see that core_id is iterated based on nr_cores.  If you strongly
> believe we need to add assert here, I will add it.
> > Let me know.
> 
> A user can emulate AMD with x2apic and intel-iommu to allow more than
> 255 vcpus and all of them can be a separate core (or its own socket),
> which would overflow this (or the next counter).
> 
> Forbidding that crazy configuration may be preferable, but an assert
> won't hurt now,

Ok. Sure. Will add assert.

> 
> thanks.
> 
> > > Thanks.
> > >
> > > > +*ecx = cpu->socket_id;
> > > > +*edx = 0;
> > > > +}
> > > > +break;
> > > >  case 0xC000:
> > > >  *eax = env->cpuid_xlevel2;
> > > >  *ebx = 0;
> > > > --
> > > > 1.8.3.1
> > > >
> 



Re: [Qemu-devel] [PATCH v2 2/5] target/i386: Populate AMD Processor Cache Information

2018-03-02 Thread Moger, Babu


> -Original Message-
> From: Radim Krčmář [mailto:rkrc...@redhat.com]
> Sent: Thursday, March 1, 2018 1:56 PM
> To: Moger, Babu 
> Cc: pbonz...@redhat.com; r...@twiddle.net; ehabk...@redhat.com;
> mtosa...@redhat.com; qemu-devel@nongnu.org; k...@vger.kernel.org;
> p...@polepetko.eu; Hook, Gary 
> Subject: Re: [PATCH v2 2/5] target/i386: Populate AMD Processor Cache
> Information
> 
> 2018-03-01 15:55+, Moger, Babu:
> > Radim, Thanks for your comments. I am working on the changes.
> > But, I need few clarifications on your comments. Please see inline.
> >
> > > -Original Message-
> > > From: Radim Krčmář [mailto:rkrc...@redhat.com]
> > > Sent: Wednesday, February 28, 2018 12:09 PM
> > > To: Moger, Babu 
> > > Cc: pbonz...@redhat.com; r...@twiddle.net; ehabk...@redhat.com;
> > > mtosa...@redhat.com; qemu-devel@nongnu.org; k...@vger.kernel.org;
> > > p...@polepetko.eu; Hook, Gary 
> > > Subject: Re: [PATCH v2 2/5] target/i386: Populate AMD Processor Cache
> > > Information
> > >
> > > 2018-02-23 21:30-0500, Babu Moger:
> > > > From: Stanislav Lanci 
> > > >
> > > > Adds information about cache size and topology from cpuid 0x801D
> > > leaf
> > > > for different cache types on AMD processors.
> > > >
> > > > Signed-off-by: Stanislav Lanci 
> > > > Signed-off-by: Babu Moger 
> > > > ---
> > > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > > @@ -3590,6 +3594,78 @@ void cpu_x86_cpuid(CPUX86State *env,
> > > > +*ebx = (L1D_LINE_SIZE - 1) | \
> > > > +   ((L1D_PARTITIONS - 1) << 12) | \
> > > > +   ((L1D_ASSOCIATIVITY - 1) << 22);
> > > > +*ecx = L1D_SETS - 1;
> > >
> > > These numbers seem to have the same meaning as CPUID 4, but have
> > > conflicting values.
> >
> > I am not sure about conflicting values. Looking at the specs(page 78
> CPUID_Fn801D_EBX_x00)
> >
> https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models_00h-
> 0Fh.pdf
> >  It looks correct to me.
> 
> I agree.  My comment is misplaced -- it should have been under the place
> that uses *_AMD macros.
> 
> I wanted to point out that CPUID in QEMU is very Intel-focused and
> always contains CPUID leaf 4, which has fields of the very same meaning,
> but with different values.
> 
> > > I think we should not expose CPUID 4 with AMD CPUs or at least when
> they
> > > have CPUID_EXT3_TOPOEXT (the latter is easier wrt. compatibility).
> >
> > Can you please elaborate on these comments?
> > Did you mean we should remove the check CPUID_EXT3_TOPOEXT and
> remove all CPUID 4 references?
> 
> CPUID 4 should have never been present when emulating AMD CPUs, but it's
> worse now that the numbers are conflicting.
> 
> I meant to hide CPUID 4 for all AMD CPUs on future machine types, or at
> least when CPUID_EXT3_TOPOEXT is enabled.

Sorry, I think I created some confusion here by using CPUID 4 definitions which 
are
mostly for intel.  Let me rework on this. I will repost the patches.  Thanks 
for the
feedback.

> 
> Keeping the current logic not a big problem as CPUID 4 should never be
> used by operating systems on AMD nor trusted inside a VM.  Bringing the
> emulation closer to real state would be nice, but this can definitely be
> done later (aka never).
> 
> > > The numbers looks like real hardware,
> >
> > Do you want me to change anything here?
> 
> No, I was just commending,
> 
> thanks.


Re: [Qemu-devel] [PATCH 4/4] virtio-net: add linkspeed and duplex settings to virtio-net

2018-03-02 Thread Jason Baron via Qemu-devel
On 03/02/2018 02:14 AM, Jason Wang wrote:
> 
> 
> On 2018年03月02日 11:46, Jason Baron wrote:
>> Although linkspeed and duplex can be set in a linux guest via 'ethtool
>> -s',
>> this requires custom ethtool commands for virtio-net by default.
>>
>> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
>> the hypervisor to export a linkspeed and duplex setting. The user can
>> subsequently overwrite it later if desired via: 'ethtool -s'.
>>
>> Linkspeed and duplex settings can be set as:
>> '-device virtio-net,speed=1,duplex=full'
> 
> I was thinking whether or not it's better to decide the duplex by the
> type of backends.
> 
> E.g userspace and vhost-kernel implement a in fact half duplex. But dpdk
> implement a full duplex.

Interesting - could this be derived only from the backend 'type'. IE:
NET_CLIENT_DRIVER_TAP, NET_CLIENT_DRIVER_VHOST_USER...


I was also thinking this could be specified as 'duplex=backend', in
addition to the proposed 'duplex=full' or 'duplex=half'?

Thanks,

-Jason

> 
> Thanks
> 
>>
>> where speed is [0...INT_MAX], and duplex is ["half"|"full"].
>>
>> Signed-off-by: Jason Baron
>> Cc: "Michael S. Tsirkin"
>> Cc: Jason Wang
>> Cc:virtio-...@lists.oasis-open.org
>> ---
> 



Re: [Qemu-devel] [PATCH 2/2] q35: change default NIC to e1000e

2018-03-02 Thread Paolo Bonzini
On 02/03/2018 18:24, Thomas Huth wrote:
> On 02.03.2018 16:51, Paolo Bonzini wrote:
>> The e1000 NIC is getting old and is not a very good default for a
>> PCIe machine type.  Change it to e1000e, which should be supported
>> by a good number of guests.
> 
> Basically a good idea, but you can only do that for new machine types
> (pc-q35-2.12 and later), otherwise migration from an older version will
> fail if the user tries to migrate with the default model.

Yeah, I was just throwing out the idea.

Paolo



[Qemu-devel] [Bug 1739371] Re: qemu-system-arm snapshot loadvm core dumped

2018-03-02 Thread Peter Maydell
*** This bug is a duplicate of bug 1739378 ***
https://bugs.launchpad.net/bugs/1739378

I'm going to close this bug as a duplicate of #1739378 (as noted in my
earlier comment).


** This bug has been marked a duplicate of bug 1739378
   migration state save/load of sdcard device is broken

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

Title:
  qemu-system-arm snapshot loadvm core dumped

Status in QEMU:
  New

Bug description:
  Ubuntu Qemu is crashing trying to restore saved snapshot in qemu-system-arm.
  I've tried different guests kernels, but I wasn't lucky with any of them.

  The guest vm boots and I can use it normally. The issue is when I save
  the snapshot using "savevm Base0", "quit" and then I restore that
  snapshot using "-loadvm Base0" from the cmd line.

  The only difference I've noticed is tweaking the guest memory:
  * With -m 512 or 1024 it crashes as you can see below.
  * With -m 2048 it doesn't crash, it restores the vm and I can see the screen 
as it was, but the OS is halted. And it's not just the keyboard. I've tried 
saving the snapshot while it's booting with lot of lines being printed on 
screen and after restoring it, the OS is frozen.

  I also tried limiting the guest kernel memory using the mem parameter
  (mem=2048M) and disabling the kernel address space randomization
  (nokaslr) with the same results.

  OS: Ubuntu 16.04.3 LTS (xenial)

  $ qemu-system-arm --version
  QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 
2003-2008 Fabrice Bellard

  $ qemu-system-arm -kernel kernel/vmlinuz-4.10.0-42-generic -initrd 
kernel/initrd.img-4.10.0-42-generic -M vexpress-a15 -m 512 -append 
'root=/dev/mmcblk0 rootwait console=tty0' -sd vexpress-4G.qcow2 -dtb 
device-tree/vexpress-v2p-ca15-tc1.dtb  -loadvm Base0
  pulseaudio: set_sink_input_volume() failed
  pulseaudio: Reason: Invalid argument
  pulseaudio: set_sink_input_mute() failed
  pulseaudio: Reason: Invalid argument
  qemu: fatal: Trying to execute code outside RAM or ROM at 0xc0321568

  R00=0001 R01= R02= R03=c0321560
  R04=c150 R05=c150529c R06=c1505234 R07=c14384d0
  R08= R09= R10=c1501f50 R11=c1501f3c
  R12=c1501f40 R13=c1501f30 R14=c030a184 R15=c0321568
  PSR=60070093 -ZC- A S svc32
  s00=6374652f s01=636f6c2f d00=636f6c2f6374652f
  s02=7273752f s03=6962732f d01=6962732f7273752f
  s04=6e612f6e s05=6f726361 d02=6f7263616e612f6e
  s06=7c7c206e s07=63202820 d03=632028207c7c206e
  s08=202f2064 s09=72202626 d04=72202626202f2064
  s10=702d6e75 s11=73747261 d05=73747261702d6e75
  s12=722d2d20 s13=726f7065 d06=726f7065722d2d20
  s14=652f2074 s15=632f6374 d07=632f6374652f2074
  s16= s17= d08=
  s18= s19= d09=
  s20= s21= d10=
  s22= s23= d11=
  s24= s25= d12=
  s26= s27= d13=
  s28= s29= d14=
  s30= s31= d15=
  s32= s33= d16=
  s34= s35= d17=
  s36= s37= d18=
  s38= s39= d19=
  s40= s41= d20=
  s42= s43= d21=
  s44= s45= d22=
  s46= s47= d23=
  s48= s49= d24=
  s50= s51= d25=
  s52= s53= d26=
  s54= s55= d27=
  s56= s57= d28=
  s58= s59= d29=
  s60= s61= d30=
  s62= s63= d31=
  FPSCR: 
  Aborted (core dumped)

  As I said above, the same happens when -m 1024 is used.

  I have a different issue when I use the qemu git master version, but
  I'm submiting a different ticket for that.

  Cheers,
  Gus

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



Re: [Qemu-devel] [PULL 0/4] tricore-patches

2018-03-02 Thread Peter Maydell
On 2 March 2018 at 11:57, Bastian Koppelmann
 wrote:
> The following changes since commit 427cbc7e4136a061628cb4315cc8182ea36d772f:
>
>   Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
> (2018-03-01 18:46:41 +)
>
> are available in the Git repository at:
>
>   https://github.com/bkoppelmann/qemu-tricore-upstream.git 
> tags/pull-tricore-2018-03-02
>
> for you to fetch changes up to ce46335c9f31f9eea1736d9c2d3a11d3a8c2cb6b:
>
>   tricore: renamed masking of PIE (2018-03-02 11:46:36 +0100)
>
> 
> tricore patches
>
> 
> David Brenken (4):
>   tricore: added some missing cpu instructions
>   tricore: added CORE_ID
>   tricore: renamed masking of IE
>   tricore: renamed masking of PIE
>
>  target/tricore/cpu.h |  7 +--
>  target/tricore/csfr.def  |  1 +
>  target/tricore/op_helper.c   | 29 +++--
>  target/tricore/translate.c   | 31 +--
>  target/tricore/tricore-opcodes.h |  3 +++
>  5 files changed, 53 insertions(+), 18 deletions(-)

Applied, thanks.

-- PMM



[Qemu-devel] [PULL 10/37] parallels: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the parallels driver accordingly.  Note that
the internal function block_status() is still sector-based, because
it is still in use by other sector-based functions; but that's okay
because request_alignment is 512 as a result of those functions.
For now, no optimizations are added based on the mapping hint.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/parallels.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/block/parallels.c b/block/parallels.c
index e1e3d80c88..3e952a9c14 100644
--- a/block/parallels.c
+++ b/block/parallels.c
@@ -261,23 +261,31 @@ static coroutine_fn int 
parallels_co_flush_to_os(BlockDriverState *bs)
 }
 
 
-static int64_t coroutine_fn parallels_co_get_block_status(BlockDriverState *bs,
-int64_t sector_num, int nb_sectors, int *pnum, BlockDriverState **file)
+static int coroutine_fn parallels_co_block_status(BlockDriverState *bs,
+  bool want_zero,
+  int64_t offset,
+  int64_t bytes,
+  int64_t *pnum,
+  int64_t *map,
+  BlockDriverState **file)
 {
 BDRVParallelsState *s = bs->opaque;
-int64_t offset;
+int count;
 
+assert(QEMU_IS_ALIGNED(offset | bytes, BDRV_SECTOR_SIZE));
 qemu_co_mutex_lock(>lock);
-offset = block_status(s, sector_num, nb_sectors, pnum);
+offset = block_status(s, offset >> BDRV_SECTOR_BITS,
+  bytes >> BDRV_SECTOR_BITS, );
 qemu_co_mutex_unlock(>lock);
 
+*pnum = count * BDRV_SECTOR_SIZE;
 if (offset < 0) {
 return 0;
 }
 
+*map = offset * BDRV_SECTOR_SIZE;
 *file = bs->file->bs;
-return (offset << BDRV_SECTOR_BITS) |
-BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID;
+return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID;
 }
 
 static coroutine_fn int parallels_co_writev(BlockDriverState *bs,
@@ -782,7 +790,7 @@ static BlockDriver bdrv_parallels = {
 .bdrv_open = parallels_open,
 .bdrv_close= parallels_close,
 .bdrv_child_perm  = bdrv_format_default_perms,
-.bdrv_co_get_block_status = parallels_co_get_block_status,
+.bdrv_co_block_status = parallels_co_block_status,
 .bdrv_has_zero_init   = bdrv_has_zero_init_1,
 .bdrv_co_flush_to_os  = parallels_co_flush_to_os,
 .bdrv_co_readv  = parallels_co_readv,
-- 
2.13.6




[Qemu-devel] [PULL 27/37] block: extract AIO_WAIT_WHILE() from BlockDriverState

2018-03-02 Thread Kevin Wolf
From: Stefan Hajnoczi 

BlockDriverState has the BDRV_POLL_WHILE() macro to wait on event loop
activity while a condition evaluates to true.  This is used to implement
synchronous operations where it acts as a condvar between the IOThread
running the operation and the main loop waiting for the operation.  It
can also be called from the thread that owns the AioContext and in that
case it's just a nested event loop.

BlockBackend needs this behavior but doesn't always have a
BlockDriverState it can use.  This patch extracts BDRV_POLL_WHILE() into
the AioWait abstraction, which can be used with AioContext and isn't
tied to BlockDriverState anymore.

This feature could be built directly into AioContext but then all users
would kick the event loop even if they signal different conditions.
Imagine an AioContext with many BlockDriverStates, each time a request
completes any waiter would wake up and re-check their condition.  It's
nicer to keep a separate AioWait object for each condition instead.

Please see "block/aio-wait.h" for details on the API.

The name AIO_WAIT_WHILE() avoids the confusion between AIO_POLL_WHILE()
and AioContext polling.

Signed-off-by: Stefan Hajnoczi 
Reviewed-by: Eric Blake 
Signed-off-by: Kevin Wolf 
---
 include/block/aio-wait.h  | 116 ++
 include/block/block.h |  40 +++-
 include/block/block_int.h |   7 ++-
 block.c   |   5 ++
 block/io.c|  10 +---
 util/aio-wait.c   |  40 
 util/Makefile.objs|   2 +-
 7 files changed, 174 insertions(+), 46 deletions(-)
 create mode 100644 include/block/aio-wait.h
 create mode 100644 util/aio-wait.c

diff --git a/include/block/aio-wait.h b/include/block/aio-wait.h
new file mode 100644
index 00..a48c744fa8
--- /dev/null
+++ b/include/block/aio-wait.h
@@ -0,0 +1,116 @@
+/*
+ * AioContext wait support
+ *
+ * Copyright (C) 2018 Red Hat, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#ifndef QEMU_AIO_WAIT_H
+#define QEMU_AIO_WAIT_H
+
+#include "block/aio.h"
+
+/**
+ * AioWait:
+ *
+ * An object that facilitates synchronous waiting on a condition.  The main
+ * loop can wait on an operation running in an IOThread as follows:
+ *
+ *   AioWait *wait = ...;
+ *   AioContext *ctx = ...;
+ *   MyWork work = { .done = false };
+ *   schedule_my_work_in_iothread(ctx, );
+ *   AIO_WAIT_WHILE(wait, ctx, !work.done);
+ *
+ * The IOThread must call aio_wait_kick() to notify the main loop when
+ * work.done changes:
+ *
+ *   static void do_work(...)
+ *   {
+ *   ...
+ *   work.done = true;
+ *   aio_wait_kick(wait);
+ *   }
+ */
+typedef struct {
+/* Is the main loop waiting for a kick?  Accessed with atomic ops. */
+bool need_kick;
+} AioWait;
+
+/**
+ * AIO_WAIT_WHILE:
+ * @wait: the aio wait object
+ * @ctx: the aio context
+ * @cond: wait while this conditional expression is true
+ *
+ * Wait while a condition is true.  Use this to implement synchronous
+ * operations that require event loop activity.
+ *
+ * The caller must be sure that something calls aio_wait_kick() when the value
+ * of @cond might have changed.
+ *
+ * The caller's thread must be the IOThread that owns @ctx or the main loop
+ * thread (with @ctx acquired exactly once).  This function cannot be used to
+ * wait on conditions between two IOThreads since that could lead to deadlock,
+ * go via the main loop instead.
+ */
+#define AIO_WAIT_WHILE(wait, ctx, cond) ({  \
+bool waited_ = false;   \
+bool busy_ = true;  \
+AioWait *wait_ = (wait);\
+AioContext *ctx_ = (ctx);   \
+if (in_aio_context_home_thread(ctx_)) { \
+while ((cond) || 

[Qemu-devel] [PULL 21/37] block: Drop unused .bdrv_co_get_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Now that all drivers have been updated to provide the
byte-based .bdrv_co_block_status(), we can delete the sector-based
interface.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 include/block/block_int.h |  3 ---
 block/io.c| 50 ++-
 2 files changed, 10 insertions(+), 43 deletions(-)

diff --git a/include/block/block_int.h b/include/block/block_int.h
index bf2598856c..5ae7738cf8 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -215,9 +215,6 @@ struct BlockDriver {
  * as well as non-NULL pnum, map, and file; in turn, the driver
  * must return an error or set pnum to an aligned non-zero value.
  */
-int64_t coroutine_fn (*bdrv_co_get_block_status)(BlockDriverState *bs,
-int64_t sector_num, int nb_sectors, int *pnum,
-BlockDriverState **file);
 int coroutine_fn (*bdrv_co_block_status)(BlockDriverState *bs,
 bool want_zero, int64_t offset, int64_t bytes, int64_t *pnum,
 int64_t *map, BlockDriverState **file);
diff --git a/block/io.c b/block/io.c
index 5bae79f282..4c3dba0973 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1963,7 +1963,7 @@ static int coroutine_fn 
bdrv_co_block_status(BlockDriverState *bs,
 
 /* Must be non-NULL or bdrv_getlength() would have failed */
 assert(bs->drv);
-if (!bs->drv->bdrv_co_get_block_status && !bs->drv->bdrv_co_block_status) {
+if (!bs->drv->bdrv_co_block_status) {
 *pnum = bytes;
 ret = BDRV_BLOCK_DATA | BDRV_BLOCK_ALLOCATED;
 if (offset + bytes == total_size) {
@@ -1981,53 +1981,23 @@ static int coroutine_fn 
bdrv_co_block_status(BlockDriverState *bs,
 
 /* Round out to request_alignment boundaries */
 align = bs->bl.request_alignment;
-if (bs->drv->bdrv_co_get_block_status && align < BDRV_SECTOR_SIZE) {
-align = BDRV_SECTOR_SIZE;
-}
 aligned_offset = QEMU_ALIGN_DOWN(offset, align);
 aligned_bytes = ROUND_UP(offset + bytes, align) - aligned_offset;
 
-if (bs->drv->bdrv_co_get_block_status) {
-int count; /* sectors */
-int64_t longret;
-
-assert(QEMU_IS_ALIGNED(aligned_offset | aligned_bytes,
-   BDRV_SECTOR_SIZE));
-/*
- * The contract allows us to return pnum smaller than bytes, even
- * if the next query would see the same status; we truncate the
- * request to avoid overflowing the driver's 32-bit interface.
- */
-longret = bs->drv->bdrv_co_get_block_status(
-bs, aligned_offset >> BDRV_SECTOR_BITS,
-MIN(INT_MAX, aligned_bytes) >> BDRV_SECTOR_BITS, ,
-_file);
-if (longret < 0) {
-assert(INT_MIN <= longret);
-ret = longret;
-goto out;
-}
-if (longret & BDRV_BLOCK_OFFSET_VALID) {
-local_map = longret & BDRV_BLOCK_OFFSET_MASK;
-}
-ret = longret & ~BDRV_BLOCK_OFFSET_MASK;
-*pnum = count * BDRV_SECTOR_SIZE;
-} else {
-ret = bs->drv->bdrv_co_block_status(bs, want_zero, aligned_offset,
-aligned_bytes, pnum, _map,
-_file);
-if (ret < 0) {
-*pnum = 0;
-goto out;
-}
-assert(*pnum); /* The block driver must make progress */
+ret = bs->drv->bdrv_co_block_status(bs, want_zero, aligned_offset,
+aligned_bytes, pnum, _map,
+_file);
+if (ret < 0) {
+*pnum = 0;
+goto out;
 }
 
 /*
- * The driver's result must be a multiple of request_alignment.
+ * The driver's result must be a non-zero multiple of request_alignment.
  * Clamp pnum and adjust map to original request.
  */
-assert(QEMU_IS_ALIGNED(*pnum, align) && align > offset - aligned_offset);
+assert(*pnum && QEMU_IS_ALIGNED(*pnum, align) &&
+   align > offset - aligned_offset);
 *pnum -= offset - aligned_offset;
 if (*pnum > bytes) {
 *pnum = bytes;
-- 
2.13.6




[Qemu-devel] [PULL 33/37] qemu-img: Make resize error message more general

2018-03-02 Thread Kevin Wolf
From: Max Reitz 

The issue:

  $ qemu-img resize -f qcow2 foo.qcow2
  qemu-img: Expecting one image file name
  Try 'qemu-img --help' for more information

So we gave an image file name, but we omitted the length.  qemu-img
thinks the last argument is always the size and removes it immediately
from argv (by decrementing argc), and tries to verify that it is a valid
size only at a later point.

So we do not actually know whether that last argument we called "size"
is indeed a size or whether the user instead forgot to specify that size
but did give a file name.

Therefore, the error message should be more general.

Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1523458
Signed-off-by: Max Reitz 
Message-id: 20180205162745.23650-1-mre...@redhat.com
Reviewed-by: John Snow 
Reviewed-by: Eric Blake 
Signed-off-by: Max Reitz 
---
 qemu-img.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/qemu-img.c b/qemu-img.c
index 56edc15218..aa99fd32e9 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -3469,7 +3469,7 @@ static int img_resize(int argc, char **argv)
 }
 }
 if (optind != argc - 1) {
-error_exit("Expecting one image file name");
+error_exit("Expecting image file name and size");
 }
 filename = argv[optind++];
 
-- 
2.13.6




[Qemu-devel] [PULL v4 28/30] qapi: Move qapi-schema.json to qapi/, rename generated files

2018-03-02 Thread Eric Blake
From: Markus Armbruster 

Move qapi-schema.json to qapi/, so it's next to its modules, and all
files get generated to qapi/, not just the ones generated for modules.

Consistently name the generated files qapi-MODULE.EXT:
qmp-commands.[ch] become qapi-commands.[ch], qapi-event.[ch] become
qapi-events.[ch], and qmp-introspect.[ch] become qapi-introspect.[ch].
This gets rid of the temporary hacks in scripts/qapi/commands.py,
scripts/qapi/events.py, and scripts/qapi/common.py.

Signed-off-by: Markus Armbruster 
Message-Id: <20180211093607.27351-28-arm...@redhat.com>
Reviewed-by: Eric Blake 
Reviewed-by: Marc-André Lureau 
Reviewed-by: Michael Roth 
[eblake: Fix trailing dot in tpm.c, undo temporary hack for OSX toolchain]
Signed-off-by: Eric Blake 
---
 docs/devel/qapi-code-gen.txt  | 30 +++---
 docs/devel/writing-qmp-commands.txt   |  2 +-
 docs/interop/qmp-intro.txt|  2 +-
 Makefile  | 42 +++
 Makefile.objs | 21 
 qapi/misc.json|  4 +--
 qapi-schema.json => qapi/qapi-schema.json | 32 +++
 include/qapi/visitor.h|  2 +-
 scripts/qapi/commands.py  |  7 --
 scripts/qapi/common.py|  5 ++--
 scripts/qapi/events.py|  9 +--
 scripts/qapi/introspect.py|  4 +--
 scripts/qapi/types.py |  6 ++---
 scripts/qapi/visit.py |  6 ++---
 include/qapi/qmp/qobject.h|  2 +-
 include/qom/object.h  |  2 +-
 backends/hostmem.c|  2 +-
 hmp.c |  2 +-
 monitor.c |  6 ++---
 net/filter-buffer.c   |  2 +-
 qga/commands-posix.c  |  2 +-
 qga/commands-win32.c  |  2 +-
 qga/commands.c|  2 +-
 qga/main.c|  2 +-
 qom/object.c  |  2 +-
 tests/test-qmp-cmds.c |  2 +-
 tests/test-qmp-event.c|  2 +-
 tests/test-qobject-input-visitor.c|  6 ++---
 tpm.c |  3 +--
 ui/vnc.c  |  2 +-
 .gitignore| 16 ++--
 qga/Makefile.objs |  2 +-
 tests/.gitignore  |  6 ++---
 tests/Makefile.include| 14 +--
 ui/cocoa.m|  2 +-
 35 files changed, 119 insertions(+), 134 deletions(-)
 rename qapi-schema.json => qapi/qapi-schema.json (85%)

diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index c86792add2e..25b7180a189 100644
--- a/docs/devel/qapi-code-gen.txt
+++ b/docs/devel/qapi-code-gen.txt
@@ -647,7 +647,7 @@ name an event 'MAX', since the generator also produces a C 
enumeration
 of all event names with a generated _MAX value at the end.  When
 'data' is also specified, additional info will be included in the
 event, with similar semantics to a 'struct' expression.  Finally there
-will be C API generated in qapi-event.h; when called by QEMU code, a
+will be C API generated in qapi-events.h; when called by QEMU code, a
 message with timestamp will be emitted on the wire.

 An example event is:
@@ -1147,15 +1147,15 @@ declares qmp_COMMAND() that the user must implement.

 The following files are generated:

-$(prefix)qmp-commands.c: Command marshal/dispatch functions for each
- QMP command defined in the schema
+$(prefix)qapi-commands.c: Command marshal/dispatch functions for each
+  QMP command defined in the schema

-$(prefix)qmp-commands.h: Function prototypes for the QMP commands
- specified in the schema
+$(prefix)qapi-commands.h: Function prototypes for the QMP commands
+  specified in the schema

 Example:

-$ cat qapi-generated/example-qmp-commands.h
+$ cat qapi-generated/example-qapi-commands.h
 [Uninteresting stuff omitted...]

 #ifndef EXAMPLE_QMP_COMMANDS_H
@@ -1170,7 +1170,7 @@ Example:
 void qmp_marshal_my_command(QDict *args, QObject **ret, Error **errp);

 #endif
-$ cat qapi-generated/example-qmp-commands.c
+$ cat qapi-generated/example-qapi-commands.c
 [Uninteresting stuff omitted...]

 static void qmp_marshal_output_UserDefOne(UserDefOne *ret_in, QObject 
**ret_out, Error **errp)
@@ -1243,14 +1243,14 @@ qapi_event_send_EVENT().

 The following files are created:

-$(prefix)qapi-event.h - Function prototypes for each event type, plus an
+$(prefix)qapi-events.h - Function prototypes for each event type, plus 

[Qemu-devel] [PULL 00/37] Block layer patches

2018-03-02 Thread Kevin Wolf
The following changes since commit 86f4c7e05b1c44dbe1b329a51f311f10aef6ff34:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180302' 
into staging (2018-03-02 14:37:10 +)

are available in the git repository at:

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

for you to fetch changes up to 9d9b4b640f9e583ff4b24dc762630945f3ccc16d:

  Merge remote-tracking branch 'mreitz/tags/pull-block-2018-03-02' into 
queue-block (2018-03-02 18:45:03 +0100)


Block layer patches


Alberto Garcia (3):
  specs/qcow2: Fix documentation of the compressed cluster descriptor
  docs: document how to use the l2-cache-entry-size parameter
  qcow2: Replace align_offset() with ROUND_UP()

Anton Nefedov (2):
  block: fix write with zero flag set and iovector provided
  iotest 033: add misaligned write-zeroes test via truncate

Eric Blake (21):
  block: Add .bdrv_co_block_status() callback
  nvme: Drop pointless .bdrv_co_get_block_status()
  block: Switch passthrough drivers to .bdrv_co_block_status()
  file-posix: Switch to .bdrv_co_block_status()
  gluster: Switch to .bdrv_co_block_status()
  iscsi: Switch cluster_sectors to byte-based
  iscsi: Switch iscsi_allocmap_update() to byte-based
  iscsi: Switch to .bdrv_co_block_status()
  null: Switch to .bdrv_co_block_status()
  parallels: Switch to .bdrv_co_block_status()
  qcow: Switch to .bdrv_co_block_status()
  qcow2: Switch to .bdrv_co_block_status()
  qed: Switch to .bdrv_co_block_status()
  raw: Switch to .bdrv_co_block_status()
  sheepdog: Switch to .bdrv_co_block_status()
  vdi: Avoid bitrot of debugging code
  vdi: Switch to .bdrv_co_block_status()
  vmdk: Switch to .bdrv_co_block_status()
  vpc: Switch to .bdrv_co_block_status()
  vvfat: Switch to .bdrv_co_block_status()
  block: Drop unused .bdrv_co_get_block_status()

Kevin Wolf (2):
  block: test blk_aio_flush() with blk->root == NULL
  Merge remote-tracking branch 'mreitz/tags/pull-block-2018-03-02' into 
queue-block

Max Reitz (4):
  qemu-img: Make resize error message more general
  block/ssh: Pull ssh_grow_file() from ssh_create()
  block/ssh: Make ssh_grow_file() blocking
  block/ssh: Add basic .bdrv_truncate()

Stefan Hajnoczi (6):
  aio: rename aio_context_in_iothread() to in_aio_context_home_thread()
  block: extract AIO_WAIT_WHILE() from BlockDriverState
  block: add BlockBackend->in_flight counter
  Revert "IDE: Do not flush empty CDROM drives"
  block: rename .bdrv_create() to .bdrv_co_create_opts()
  qcow2: make qcow2_co_create2() a coroutine_fn

 docs/interop/qcow2.txt |  16 -
 docs/qcow2-cache.txt   |  46 -
 block/qcow2.h  |   6 --
 include/block/aio-wait.h   | 116 
 include/block/aio.h|   7 +-
 include/block/block.h  |  54 ---
 include/block/block_int.h  |  61 ++---
 block.c|  11 ++-
 block/blkdebug.c   |  20 +++---
 block/block-backend.c  |  60 +++--
 block/commit.c |   2 +-
 block/crypto.c |   8 +--
 block/file-posix.c |  79 +++---
 block/file-win32.c |   5 +-
 block/gluster.c|  83 ---
 block/io.c |  98 +++
 block/iscsi.c  | 164 -
 block/mirror.c |   2 +-
 block/nfs.c|   5 +-
 block/null.c   |  23 ---
 block/nvme.c   |  14 
 block/parallels.c  |  28 +---
 block/qcow.c   |  32 +
 block/qcow2-bitmap.c   |   4 +-
 block/qcow2-cluster.c  |   4 +-
 block/qcow2-refcount.c |   4 +-
 block/qcow2-snapshot.c |  10 +--
 block/qcow2.c  |  60 +
 block/qed.c|  82 ---
 block/raw-format.c |  21 +++---
 block/rbd.c|   6 +-
 block/sheepdog.c   |  36 +-
 block/ssh.c|  66 +++---
 block/throttle.c   |   2 +-
 block/vdi.c|  50 +++---
 block/vhdx.c   |   5 +-
 block/vmdk.c   |  43 +---
 block/vpc.c|  50 +++---
 block/vvfat.c  |  16 ++---
 hw/ide/core.c  |  10 +--
 qemu-img.c |   2 +-
 tests/test-block-backend.c |  82 +++
 util/aio-wait.c|  40 +++
 tests/Makefile.include |   2 +
 tests/qemu-iotests/033 |  29 
 tests/qemu-iotests/033.out |  13 
 util/Makefile.objs |   2 +-
 47 files changed, 973 insertions(+), 606 deletions(-)
 create mode 100644 i

[Qemu-devel] [PULL 12/37] qcow2: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the qcow2 driver accordingly.

For now, we are ignoring the 'want_zero' hint.  However, it should
be relatively straightforward to honor the hint as a way to return
larger *pnum values when we have consecutive clusters with the same
data/zero status but which differ only in having non-consecutive
mappings.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/qcow2.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index 57a517e2bd..288b5299d8 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1670,32 +1670,34 @@ static void qcow2_join_options(QDict *options, QDict 
*old_options)
 }
 }
 
-static int64_t coroutine_fn qcow2_co_get_block_status(BlockDriverState *bs,
-int64_t sector_num, int nb_sectors, int *pnum, BlockDriverState **file)
+static int coroutine_fn qcow2_co_block_status(BlockDriverState *bs,
+  bool want_zero,
+  int64_t offset, int64_t count,
+  int64_t *pnum, int64_t *map,
+  BlockDriverState **file)
 {
 BDRVQcow2State *s = bs->opaque;
 uint64_t cluster_offset;
 int index_in_cluster, ret;
 unsigned int bytes;
-int64_t status = 0;
+int status = 0;
 
-bytes = MIN(INT_MAX, nb_sectors * BDRV_SECTOR_SIZE);
+bytes = MIN(INT_MAX, count);
 qemu_co_mutex_lock(>lock);
-ret = qcow2_get_cluster_offset(bs, sector_num << BDRV_SECTOR_BITS, ,
-   _offset);
+ret = qcow2_get_cluster_offset(bs, offset, , _offset);
 qemu_co_mutex_unlock(>lock);
 if (ret < 0) {
 return ret;
 }
 
-*pnum = bytes >> BDRV_SECTOR_BITS;
+*pnum = bytes;
 
 if (cluster_offset != 0 && ret != QCOW2_CLUSTER_COMPRESSED &&
 !s->crypto) {
-index_in_cluster = sector_num & (s->cluster_sectors - 1);
-cluster_offset |= (index_in_cluster << BDRV_SECTOR_BITS);
+index_in_cluster = offset & (s->cluster_size - 1);
+*map = cluster_offset | index_in_cluster;
 *file = bs->file->bs;
-status |= BDRV_BLOCK_OFFSET_VALID | cluster_offset;
+status |= BDRV_BLOCK_OFFSET_VALID;
 }
 if (ret == QCOW2_CLUSTER_ZERO_PLAIN || ret == QCOW2_CLUSTER_ZERO_ALLOC) {
 status |= BDRV_BLOCK_ZERO;
@@ -4352,7 +4354,7 @@ BlockDriver bdrv_qcow2 = {
 .bdrv_child_perm  = bdrv_format_default_perms,
 .bdrv_create= qcow2_create,
 .bdrv_has_zero_init = bdrv_has_zero_init_1,
-.bdrv_co_get_block_status = qcow2_co_get_block_status,
+.bdrv_co_block_status = qcow2_co_block_status,
 
 .bdrv_co_preadv = qcow2_co_preadv,
 .bdrv_co_pwritev= qcow2_co_pwritev,
-- 
2.13.6




[Qemu-devel] [PULL 01/37] block: Add .bdrv_co_block_status() callback

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based. Now that the block layer exposes byte-based allocation,
it's time to tackle the drivers.  Add a new callback that operates
on as small as byte boundaries. Subsequent patches will then update
individual drivers, then finally remove .bdrv_co_get_block_status().

The new code also passes through the 'want_zero' hint, which will
allow subsequent patches to further optimize callers that only care
about how much of the image is allocated (want_zero is false),
rather than full details about runs of zeroes and which offsets the
allocation actually maps to (want_zero is true).  As part of this
effort, fix another part of the documentation: the claim in commit
4c41cb4 that BDRV_BLOCK_ALLOCATED is short for 'DATA || ZERO' is a
lie at the block layer (see commit e88ae2264), even though it is
how the bit is computed from the driver layer.  After all, there
are intentionally cases where we return ZERO but not ALLOCATED at
the block layer, when we know that a read sees zero because the
backing file is too short.  Note that the driver interface is thus
slightly different than the public interface with regards to which
bits will be set, and what guarantees are provided on input.

We also add an assertion that any driver using the new callback will
make progress (the only time pnum will be 0 is if the block layer
already handled an out-of-bounds request, or if there is an error);
the old driver interface did not provide this guarantee, which
could lead to some inf-loops in drastic corner-case failures.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 include/block/block.h | 14 +++---
 include/block/block_int.h | 20 +++-
 block/io.c| 28 +++-
 3 files changed, 41 insertions(+), 21 deletions(-)

diff --git a/include/block/block.h b/include/block/block.h
index 19b3ab9cb5..947e8876cd 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -115,19 +115,19 @@ typedef struct HDGeometry {
  * BDRV_BLOCK_ZERO: offset reads as zero
  * BDRV_BLOCK_OFFSET_VALID: an associated offset exists for accessing raw data
  * BDRV_BLOCK_ALLOCATED: the content of the block is determined by this
- *   layer (short for DATA || ZERO), set by block layer
- * BDRV_BLOCK_EOF: the returned pnum covers through end of file for this layer
+ *   layer rather than any backing, set by block layer
+ * BDRV_BLOCK_EOF: the returned pnum covers through end of file for this
+ * layer, set by block layer
  *
  * Internal flag:
  * BDRV_BLOCK_RAW: for use by passthrough drivers, such as raw, to request
  * that the block layer recompute the answer from the returned
  * BDS; must be accompanied by just BDRV_BLOCK_OFFSET_VALID.
  *
- * If BDRV_BLOCK_OFFSET_VALID is set, bits 9-62 (BDRV_BLOCK_OFFSET_MASK) of
- * the return value (old interface) or the entire map parameter (new
- * interface) represent the offset in the returned BDS that is allocated for
- * the corresponding raw data.  However, whether that offset actually
- * contains data also depends on BDRV_BLOCK_DATA, as follows:
+ * If BDRV_BLOCK_OFFSET_VALID is set, the map parameter represents the
+ * host offset within the returned BDS that is allocated for the
+ * corresponding raw guest data.  However, whether that offset
+ * actually contains data also depends on BDRV_BLOCK_DATA, as follows:
  *
  * DATA ZERO OFFSET_VALID
  *  ttt   sectors read as zero, returned file is zero at offset
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 5ea63f8fa8..c93722b43a 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -202,15 +202,25 @@ struct BlockDriver {
 /*
  * Building block for bdrv_block_status[_above] and
  * bdrv_is_allocated[_above].  The driver should answer only
- * according to the current layer, and should not set
- * BDRV_BLOCK_ALLOCATED, but may set BDRV_BLOCK_RAW.  See block.h
- * for the meaning of _DATA, _ZERO, and _OFFSET_VALID.  The block
- * layer guarantees input aligned to request_alignment, as well as
- * non-NULL pnum and file.
+ * according to the current layer, and should only need to set
+ * BDRV_BLOCK_DATA, BDRV_BLOCK_ZERO, BDRV_BLOCK_OFFSET_VALID,
+ * and/or BDRV_BLOCK_RAW; if the current layer defers to a backing
+ * layer, the result should be 0 (and not BDRV_BLOCK_ZERO).  See
+ * block.h for the overall meaning of the bits.  As a hint, the
+ * flag want_zero is true if the caller cares more about precise
+ * mappings (favor accurate _OFFSET_VALID/_ZERO) or false for
+ * overall allocation (favor larger *pnum, perhaps by 

[Qemu-devel] [PULL 07/37] iscsi: Switch iscsi_allocmap_update() to byte-based

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based.  Convert all uses of
the allocmap (no semantic change).  Callers that already had bytes
available are simpler, and callers that now scale to bytes will be
easier to switch to byte-based in the future.

Signed-off-by: Eric Blake 
Acked-by: Paolo Bonzini 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/iscsi.c | 90 +--
 1 file changed, 44 insertions(+), 46 deletions(-)

diff --git a/block/iscsi.c b/block/iscsi.c
index 3414c21c7f..d2b0466775 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -458,24 +458,22 @@ static int iscsi_allocmap_init(IscsiLun *iscsilun, int 
open_flags)
 }
 
 static void
-iscsi_allocmap_update(IscsiLun *iscsilun, int64_t sector_num,
-  int nb_sectors, bool allocated, bool valid)
+iscsi_allocmap_update(IscsiLun *iscsilun, int64_t offset,
+  int64_t bytes, bool allocated, bool valid)
 {
 int64_t cl_num_expanded, nb_cls_expanded, cl_num_shrunk, nb_cls_shrunk;
-int cluster_sectors = iscsilun->cluster_size >> BDRV_SECTOR_BITS;
 
 if (iscsilun->allocmap == NULL) {
 return;
 }
 /* expand to entirely contain all affected clusters */
-assert(cluster_sectors);
-cl_num_expanded = sector_num / cluster_sectors;
-nb_cls_expanded = DIV_ROUND_UP(sector_num + nb_sectors,
-   cluster_sectors) - cl_num_expanded;
+assert(iscsilun->cluster_size);
+cl_num_expanded = offset / iscsilun->cluster_size;
+nb_cls_expanded = DIV_ROUND_UP(offset + bytes,
+   iscsilun->cluster_size) - cl_num_expanded;
 /* shrink to touch only completely contained clusters */
-cl_num_shrunk = DIV_ROUND_UP(sector_num, cluster_sectors);
-nb_cls_shrunk = (sector_num + nb_sectors) / cluster_sectors
-  - cl_num_shrunk;
+cl_num_shrunk = DIV_ROUND_UP(offset, iscsilun->cluster_size);
+nb_cls_shrunk = (offset + bytes) / iscsilun->cluster_size - cl_num_shrunk;
 if (allocated) {
 bitmap_set(iscsilun->allocmap, cl_num_expanded, nb_cls_expanded);
 } else {
@@ -498,26 +496,26 @@ iscsi_allocmap_update(IscsiLun *iscsilun, int64_t 
sector_num,
 }
 
 static void
-iscsi_allocmap_set_allocated(IscsiLun *iscsilun, int64_t sector_num,
- int nb_sectors)
+iscsi_allocmap_set_allocated(IscsiLun *iscsilun, int64_t offset,
+ int64_t bytes)
 {
-iscsi_allocmap_update(iscsilun, sector_num, nb_sectors, true, true);
+iscsi_allocmap_update(iscsilun, offset, bytes, true, true);
 }
 
 static void
-iscsi_allocmap_set_unallocated(IscsiLun *iscsilun, int64_t sector_num,
-   int nb_sectors)
+iscsi_allocmap_set_unallocated(IscsiLun *iscsilun, int64_t offset,
+   int64_t bytes)
 {
 /* Note: if cache.direct=on the fifth argument to iscsi_allocmap_update
  * is ignored, so this will in effect be an iscsi_allocmap_set_invalid.
  */
-iscsi_allocmap_update(iscsilun, sector_num, nb_sectors, false, true);
+iscsi_allocmap_update(iscsilun, offset, bytes, false, true);
 }
 
-static void iscsi_allocmap_set_invalid(IscsiLun *iscsilun, int64_t sector_num,
-   int nb_sectors)
+static void iscsi_allocmap_set_invalid(IscsiLun *iscsilun, int64_t offset,
+   int64_t bytes)
 {
-iscsi_allocmap_update(iscsilun, sector_num, nb_sectors, false, false);
+iscsi_allocmap_update(iscsilun, offset, bytes, false, false);
 }
 
 static void iscsi_allocmap_invalidate(IscsiLun *iscsilun)
@@ -531,34 +529,30 @@ static void iscsi_allocmap_invalidate(IscsiLun *iscsilun)
 }
 
 static inline bool
-iscsi_allocmap_is_allocated(IscsiLun *iscsilun, int64_t sector_num,
-int nb_sectors)
+iscsi_allocmap_is_allocated(IscsiLun *iscsilun, int64_t offset,
+int64_t bytes)
 {
 unsigned long size;
 if (iscsilun->allocmap == NULL) {
 return true;
 }
 assert(iscsilun->cluster_size);
-size = DIV_ROUND_UP(sector_num + nb_sectors,
-iscsilun->cluster_size >> BDRV_SECTOR_BITS);
+size = DIV_ROUND_UP(offset + bytes, iscsilun->cluster_size);
 return !(find_next_bit(iscsilun->allocmap, size,
-   sector_num * BDRV_SECTOR_SIZE /
-   iscsilun->cluster_size) == size);
+   offset / iscsilun->cluster_size) == size);
 }
 
 static inline bool iscsi_allocmap_is_valid(IscsiLun *iscsilun,
-   int64_t sector_num, int nb_sectors)
+   int64_t offset, int64_t bytes)
 {
 unsigned 

[Qemu-devel] [PULL 08/37] iscsi: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the iscsi driver accordingly.  In this case,
it is handy to teach iscsi_co_block_status() to handle a NULL map
and file parameter, even though the block layer passes non-NULL
values, because we also call the function directly.  For now, there
are no optimizations done based on the want_zero flag.

We can also make the simplification of asserting that the block
layer passed in aligned values.

Signed-off-by: Eric Blake 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/iscsi.c | 69 ---
 1 file changed, 33 insertions(+), 36 deletions(-)

diff --git a/block/iscsi.c b/block/iscsi.c
index d2b0466775..c228ca21c8 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -653,36 +653,36 @@ out_unlock:
 
 
 
-static int64_t coroutine_fn iscsi_co_get_block_status(BlockDriverState *bs,
-  int64_t sector_num,
-  int nb_sectors, int *pnum,
-  BlockDriverState **file)
+static int coroutine_fn iscsi_co_block_status(BlockDriverState *bs,
+  bool want_zero, int64_t offset,
+  int64_t bytes, int64_t *pnum,
+  int64_t *map,
+  BlockDriverState **file)
 {
 IscsiLun *iscsilun = bs->opaque;
 struct scsi_get_lba_status *lbas = NULL;
 struct scsi_lba_status_descriptor *lbasd = NULL;
 struct IscsiTask iTask;
 uint64_t lba;
-int64_t ret;
+int ret;
 
 iscsi_co_init_iscsitask(iscsilun, );
 
-if (!is_sector_request_lun_aligned(sector_num, nb_sectors, iscsilun)) {
-ret = -EINVAL;
-goto out;
-}
+assert(QEMU_IS_ALIGNED(offset | bytes, iscsilun->block_size));
 
 /* default to all sectors allocated */
-ret = BDRV_BLOCK_DATA;
-ret |= (sector_num << BDRV_SECTOR_BITS) | BDRV_BLOCK_OFFSET_VALID;
-*pnum = nb_sectors;
+ret = BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID;
+if (map) {
+*map = offset;
+}
+*pnum = bytes;
 
 /* LUN does not support logical block provisioning */
 if (!iscsilun->lbpme) {
 goto out;
 }
 
-lba = sector_qemu2lun(sector_num, iscsilun);
+lba = offset / iscsilun->block_size;
 
 qemu_mutex_lock(>mutex);
 retry:
@@ -727,12 +727,12 @@ retry:
 
 lbasd = >descriptors[0];
 
-if (sector_qemu2lun(sector_num, iscsilun) != lbasd->lba) {
+if (lba != lbasd->lba) {
 ret = -EIO;
 goto out_unlock;
 }
 
-*pnum = sector_lun2qemu(lbasd->num_blocks, iscsilun);
+*pnum = lbasd->num_blocks * iscsilun->block_size;
 
 if (lbasd->provisioning == SCSI_PROVISIONING_TYPE_DEALLOCATED ||
 lbasd->provisioning == SCSI_PROVISIONING_TYPE_ANCHORED) {
@@ -743,15 +743,13 @@ retry:
 }
 
 if (ret & BDRV_BLOCK_ZERO) {
-iscsi_allocmap_set_unallocated(iscsilun, sector_num * BDRV_SECTOR_SIZE,
-   *pnum * BDRV_SECTOR_SIZE);
+iscsi_allocmap_set_unallocated(iscsilun, offset, *pnum);
 } else {
-iscsi_allocmap_set_allocated(iscsilun, sector_num * BDRV_SECTOR_SIZE,
- *pnum * BDRV_SECTOR_SIZE);
+iscsi_allocmap_set_allocated(iscsilun, offset, *pnum);
 }
 
-if (*pnum > nb_sectors) {
-*pnum = nb_sectors;
+if (*pnum > bytes) {
+*pnum = bytes;
 }
 out_unlock:
 qemu_mutex_unlock(>mutex);
@@ -760,7 +758,7 @@ out:
 if (iTask.task != NULL) {
 scsi_free_scsi_task(iTask.task);
 }
-if (ret > 0 && ret & BDRV_BLOCK_OFFSET_VALID) {
+if (ret > 0 && ret & BDRV_BLOCK_OFFSET_VALID && file) {
 *file = bs;
 }
 return ret;
@@ -800,25 +798,24 @@ static int coroutine_fn iscsi_co_readv(BlockDriverState 
*bs,
  nb_sectors * BDRV_SECTOR_SIZE) &&
 !iscsi_allocmap_is_allocated(iscsilun, sector_num * BDRV_SECTOR_SIZE,
  nb_sectors * BDRV_SECTOR_SIZE)) {
-int pnum;
-BlockDriverState *file;
+int64_t pnum;
 /* check the block status from the beginning of the cluster
  * containing the start sector */
-int cluster_sectors = iscsilun->cluster_size >> BDRV_SECTOR_BITS;
-int head;
-int64_t ret;
-
-assert(cluster_sectors);
-head = sector_num % cluster_sectors;
-ret = iscsi_co_get_block_status(bs, sector_num - head,
-BDRV_REQUEST_MAX_SECTORS, ,
-);
+int64_t head;
+int ret;
+
+assert(iscsilun->cluster_size);
+head = (sector_num 

[Qemu-devel] [PULL 18/37] vmdk: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the vmdk driver accordingly.  Drop the
now-unused vmdk_find_index_in_cluster().

Also, fix a pre-existing bug: if find_extent() fails (unlikely,
since the block layer did a bounds check), then we must return a
failure, rather than 0.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/vmdk.c | 38 ++
 1 file changed, 14 insertions(+), 24 deletions(-)

diff --git a/block/vmdk.c b/block/vmdk.c
index ef15ddbfd3..75f84213e6 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1304,33 +1304,27 @@ static inline uint64_t 
vmdk_find_offset_in_cluster(VmdkExtent *extent,
 return extent_relative_offset % cluster_size;
 }
 
-static inline uint64_t vmdk_find_index_in_cluster(VmdkExtent *extent,
-  int64_t sector_num)
-{
-uint64_t offset;
-offset = vmdk_find_offset_in_cluster(extent, sector_num * 
BDRV_SECTOR_SIZE);
-return offset / BDRV_SECTOR_SIZE;
-}
-
-static int64_t coroutine_fn vmdk_co_get_block_status(BlockDriverState *bs,
-int64_t sector_num, int nb_sectors, int *pnum, BlockDriverState **file)
+static int coroutine_fn vmdk_co_block_status(BlockDriverState *bs,
+ bool want_zero,
+ int64_t offset, int64_t bytes,
+ int64_t *pnum, int64_t *map,
+ BlockDriverState **file)
 {
 BDRVVmdkState *s = bs->opaque;
 int64_t index_in_cluster, n, ret;
-uint64_t offset;
+uint64_t cluster_offset;
 VmdkExtent *extent;
 
-extent = find_extent(s, sector_num, NULL);
+extent = find_extent(s, offset >> BDRV_SECTOR_BITS, NULL);
 if (!extent) {
-return 0;
+return -EIO;
 }
 qemu_co_mutex_lock(>lock);
-ret = get_cluster_offset(bs, extent, NULL,
- sector_num * 512, false, ,
+ret = get_cluster_offset(bs, extent, NULL, offset, false, _offset,
  0, 0);
 qemu_co_mutex_unlock(>lock);
 
-index_in_cluster = vmdk_find_index_in_cluster(extent, sector_num);
+index_in_cluster = vmdk_find_offset_in_cluster(extent, offset);
 switch (ret) {
 case VMDK_ERROR:
 ret = -EIO;
@@ -1345,18 +1339,14 @@ static int64_t coroutine_fn 
vmdk_co_get_block_status(BlockDriverState *bs,
 ret = BDRV_BLOCK_DATA;
 if (!extent->compressed) {
 ret |= BDRV_BLOCK_OFFSET_VALID;
-ret |= (offset + (index_in_cluster << BDRV_SECTOR_BITS))
-& BDRV_BLOCK_OFFSET_MASK;
+*map = cluster_offset + index_in_cluster;
 }
 *file = extent->file->bs;
 break;
 }
 
-n = extent->cluster_sectors - index_in_cluster;
-if (n > nb_sectors) {
-n = nb_sectors;
-}
-*pnum = n;
+n = extent->cluster_sectors * BDRV_SECTOR_SIZE - index_in_cluster;
+*pnum = MIN(n, bytes);
 return ret;
 }
 
@@ -2410,7 +2400,7 @@ static BlockDriver bdrv_vmdk = {
 .bdrv_close   = vmdk_close,
 .bdrv_create  = vmdk_create,
 .bdrv_co_flush_to_disk= vmdk_co_flush,
-.bdrv_co_get_block_status = vmdk_co_get_block_status,
+.bdrv_co_block_status = vmdk_co_block_status,
 .bdrv_get_allocated_file_size = vmdk_get_allocated_file_size,
 .bdrv_has_zero_init   = vmdk_has_zero_init,
 .bdrv_get_specific_info   = vmdk_get_specific_info,
-- 
2.13.6




[Qemu-devel] [PULL 24/37] specs/qcow2: Fix documentation of the compressed cluster descriptor

2018-03-02 Thread Kevin Wolf
From: Alberto Garcia 

This patch fixes several mistakes in the documentation of the
compressed cluster descriptor:

1) the documentation claims that the cluster descriptor contains the
   number of sectors used to store the compressed data, but what it
   actually contains is the number of sectors *minus one* or, in other
   words, the number of additional sectors after the first one.

2) the width of the fields is incorrectly specified. The number of bits
   used by each field is

  x = 62 - (cluster_bits - 8)   for the offset field
  y = (cluster_bits - 8)for the size field

   So the offset field's location is [0, x-1], not [0, x] as stated.

3) the size field does not contain the size of the compressed data,
   but rather the number of sectors where that data is stored. The
   compressed data starts at the exact point specified in the offset
   field and ends when there's enough data to produce a cluster of
   decompressed data. Both points can be in the middle of a sector,
   allowing several compressed clusters to be stored next to one
   another, sharing sectors if necessary.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Alberto Garcia 
Reviewed-by: Eric Blake 
Signed-off-by: Kevin Wolf 
---
 docs/interop/qcow2.txt | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
index d7fdb1fee3..feb711fb6a 100644
--- a/docs/interop/qcow2.txt
+++ b/docs/interop/qcow2.txt
@@ -426,10 +426,20 @@ Standard Cluster Descriptor:
 
 Compressed Clusters Descriptor (x = 62 - (cluster_bits - 8)):
 
-Bit  0 -  x:Host cluster offset. This is usually _not_ aligned to a
-cluster boundary!
+Bit  0 - x-1:   Host cluster offset. This is usually _not_ aligned to a
+cluster or sector boundary!
 
-   x+1 - 61:Compressed size of the images in sectors of 512 bytes
+ x - 61:Number of additional 512-byte sectors used for the
+compressed data, beyond the sector containing the offset
+in the previous field. Some of these sectors may reside
+in the next contiguous host cluster.
+
+Note that the compressed data does not necessarily occupy
+all of the bytes in the final sector; rather, decompression
+stops when it has produced a cluster of data.
+
+Another compressed cluster may map to the tail of the final
+sector used by this compressed cluster.
 
 If a cluster is unallocated, read requests shall read the data from the backing
 file (except if bit 0 in the Standard Cluster Descriptor is set). If there is
-- 
2.13.6




[Qemu-devel] [PULL 31/37] block: rename .bdrv_create() to .bdrv_co_create_opts()

2018-03-02 Thread Kevin Wolf
From: Stefan Hajnoczi 

BlockDriver->bdrv_create() has been called from coroutine context since
commit 5b7e1542cfa41a281af9629d31cef03704d976e6 ("block: make
bdrv_create adopt coroutine").

Make this explicit by renaming to .bdrv_co_create_opts() and add the
coroutine_fn annotation.  This makes it obvious to block driver authors
that they may yield, use CoMutex, or other coroutine_fn APIs.
bdrv_co_create is reserved for the QAPI-based version that Kevin is
working on.

Signed-off-by: Stefan Hajnoczi 
Message-Id: <20170705102231.20711-2-stefa...@redhat.com>
Signed-off-by: Paolo Bonzini 
Reviewed-by: Eric Blake 
Signed-off-by: Kevin Wolf 
---
 include/block/block_int.h |  3 ++-
 block.c   |  4 ++--
 block/crypto.c|  8 
 block/file-posix.c| 15 ---
 block/file-win32.c|  5 +++--
 block/gluster.c   | 13 +++--
 block/iscsi.c |  7 ---
 block/nfs.c   |  5 +++--
 block/parallels.c |  6 --
 block/qcow.c  |  5 +++--
 block/qcow2.c |  5 +++--
 block/qed.c   |  6 --
 block/raw-format.c|  5 +++--
 block/rbd.c   |  6 --
 block/sheepdog.c  | 10 +-
 block/ssh.c   |  5 +++--
 block/vdi.c   |  5 +++--
 block/vhdx.c  |  5 +++--
 block/vmdk.c  |  5 +++--
 block/vpc.c   |  5 +++--
 20 files changed, 74 insertions(+), 54 deletions(-)

diff --git a/include/block/block_int.h b/include/block/block_int.h
index aef10296b0..64a5700f2b 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -129,7 +129,8 @@ struct BlockDriver {
 int (*bdrv_file_open)(BlockDriverState *bs, QDict *options, int flags,
   Error **errp);
 void (*bdrv_close)(BlockDriverState *bs);
-int (*bdrv_create)(const char *filename, QemuOpts *opts, Error **errp);
+int coroutine_fn (*bdrv_co_create_opts)(const char *filename, QemuOpts 
*opts,
+   Error **errp);
 int (*bdrv_make_empty)(BlockDriverState *bs);
 
 void (*bdrv_refresh_filename)(BlockDriverState *bs, QDict *options);
diff --git a/block.c b/block.c
index a83037c2a5..86dd809041 100644
--- a/block.c
+++ b/block.c
@@ -420,7 +420,7 @@ static void coroutine_fn bdrv_create_co_entry(void *opaque)
 CreateCo *cco = opaque;
 assert(cco->drv);
 
-ret = cco->drv->bdrv_create(cco->filename, cco->opts, _err);
+ret = cco->drv->bdrv_co_create_opts(cco->filename, cco->opts, _err);
 error_propagate(>err, local_err);
 cco->ret = ret;
 }
@@ -439,7 +439,7 @@ int bdrv_create(BlockDriver *drv, const char* filename,
 .err = NULL,
 };
 
-if (!drv->bdrv_create) {
+if (!drv->bdrv_co_create_opts) {
 error_setg(errp, "Driver '%s' does not support image creation", 
drv->format_name);
 ret = -ENOTSUP;
 goto out;
diff --git a/block/crypto.c b/block/crypto.c
index 3df66947c5..2ea116e6db 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -556,9 +556,9 @@ static int block_crypto_open_luks(BlockDriverState *bs,
  bs, options, flags, errp);
 }
 
-static int block_crypto_create_luks(const char *filename,
-QemuOpts *opts,
-Error **errp)
+static int coroutine_fn block_crypto_co_create_opts_luks(const char *filename,
+ QemuOpts *opts,
+ Error **errp)
 {
 return block_crypto_create_generic(Q_CRYPTO_BLOCK_FORMAT_LUKS,
filename, opts, errp);
@@ -617,7 +617,7 @@ BlockDriver bdrv_crypto_luks = {
 .bdrv_open  = block_crypto_open_luks,
 .bdrv_close = block_crypto_close,
 .bdrv_child_perm= bdrv_format_default_perms,
-.bdrv_create= block_crypto_create_luks,
+.bdrv_co_create_opts = block_crypto_co_create_opts_luks,
 .bdrv_truncate  = block_crypto_truncate,
 .create_opts= _crypto_create_opts_luks,
 
diff --git a/block/file-posix.c b/block/file-posix.c
index f1591c3849..7f2cc63c60 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1982,7 +1982,8 @@ static int64_t 
raw_get_allocated_file_size(BlockDriverState *bs)
 return (int64_t)st.st_blocks * 512;
 }
 
-static int raw_create(const char *filename, QemuOpts *opts, Error **errp)
+static int coroutine_fn raw_co_create_opts(const char *filename, QemuOpts 
*opts,
+   Error **errp)
 {
 int fd;
 int result = 0;
@@ -2276,7 +2277,7 @@ BlockDriver bdrv_file = {
 .bdrv_reopen_commit = raw_reopen_commit,
 .bdrv_reopen_abort = raw_reopen_abort,
 .bdrv_close = raw_close,
-.bdrv_create = raw_create,
+   

[Qemu-devel] [PULL 36/37] block/ssh: Add basic .bdrv_truncate()

2018-03-02 Thread Kevin Wolf
From: Max Reitz 

libssh2 does not seem to offer real truncation support, so we can only
grow files -- but that is better than nothing.

Signed-off-by: Max Reitz 
Message-id: 20180214204915.7980-4-mre...@redhat.com
Reviewed-by: Eric Blake 
Reviewed-by: Richard W.M. Jones 
Signed-off-by: Max Reitz 
---
 block/ssh.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/block/ssh.c b/block/ssh.c
index 4bcf10334f..80a8b40dfa 100644
--- a/block/ssh.c
+++ b/block/ssh.c
@@ -1220,6 +1220,29 @@ static int64_t ssh_getlength(BlockDriverState *bs)
 return length;
 }
 
+static int ssh_truncate(BlockDriverState *bs, int64_t offset,
+PreallocMode prealloc, Error **errp)
+{
+BDRVSSHState *s = bs->opaque;
+
+if (prealloc != PREALLOC_MODE_OFF) {
+error_setg(errp, "Unsupported preallocation mode '%s'",
+   PreallocMode_str(prealloc));
+return -ENOTSUP;
+}
+
+if (offset < s->attrs.filesize) {
+error_setg(errp, "ssh driver does not support shrinking files");
+return -ENOTSUP;
+}
+
+if (offset == s->attrs.filesize) {
+return 0;
+}
+
+return ssh_grow_file(s, offset, errp);
+}
+
 static BlockDriver bdrv_ssh = {
 .format_name  = "ssh",
 .protocol_name= "ssh",
@@ -1232,6 +1255,7 @@ static BlockDriver bdrv_ssh = {
 .bdrv_co_readv= ssh_co_readv,
 .bdrv_co_writev   = ssh_co_writev,
 .bdrv_getlength   = ssh_getlength,
+.bdrv_truncate= ssh_truncate,
 .bdrv_co_flush_to_disk= ssh_co_flush,
 .create_opts  = _create_opts,
 };
-- 
2.13.6




Re: [Qemu-devel] [PATCH v2 5/5] s390x/cpumodel: Set up CPU model for AP device support

2018-03-02 Thread Tony Krowiak

On 03/01/2018 09:36 AM, David Hildenbrand wrote:

On 01.03.2018 15:12, Pierre Morel wrote:

On 28/02/2018 12:40, Cornelia Huck wrote:

On Wed, 28 Feb 2018 11:26:30 +0100
David Hildenbrand  wrote:


Then I request the following change in KVM:

If KVM_S390_VM_CPU_FEAT_AP is enabled in KVM, ECA.28 is _always_ set
(not just if an AP device is configured). This especially makes things a
lot easier when it comes to handling hotplugged CPUs and avoiding race
conditions when enabling these bits as mentioned in the KVM series.

KVM_S390_VM_CPU_FEAT_AP == AP instructions available for the guest
(don't throw an operation exception).

So this feature then really is guest ABI. The instructions are
available. If there is no device configured, bad luck.

Sounds sensible from my POV.


I have a concern with this proposition and with the original code:

Very good, this is exactly what I talked to Conny about yesterday.

Short version: CPU model is guest ABI, everything else is configuration.


1) ap=on is a guest ABI feature saying to the guest you can use AP
instructions

Indeed, that's what belongs into the CPU model.


2) How we provide AP instructions to the guest can be done in three
different ways:
   - SIE Interpretation
   - interception with VFIO
   - interception with emulation


Due to bad AP design we can't handle this like zPCI - completely in
QEMU. That's what should control it.


3) We implement this with a device in QEMU and a certain level kernel
support.

It seems possible to set or not ECA.28 , based on the type of kernel device:
- SIE interpretation -> MATRIX KVM device -> ECA.28
- Interception with VFIO and virtualization -> no ECA.28
- interception with emulation -> no ECA.28

I understand the concern with the vCPU but I think we can handle it with
an indirect variable
like:

SIE interpretation Device + KVM_S390_VM_CPU_FEAT_AP -> set the variable
ap_to_be_sie_interpreted=1
Then in vCPU initialization set ECA.28 based on this variable.

That's exactly why we have the cpu feature interface. E.g. CMMA -> if
not enabled, not interpreted by HW (however also not intercepted to user
space - no sense in doing that right now).

I'm not sure I am interpreting what you are saying here correctly, but
in the case of AP, if ECA.28 is not set, the AP instructions will not be
interpreted by HW but WILL be intercepted and forwarded to user space.



I think it let us more doors open, what is your opinion?

In general, for now we don't care. The kernel is the only AP bus provider.

If KVM presents AP support -> AP feature can be enabled. And it should
always enable it.

Once we have a QEMU AP bus implementation, things get more complicated.
We could provide the AP feature also without KVM (like zPCI).

But weather or not to enable the KVM control has to be concluded from
the other configuration. Only user space can now that and has to decide
before enabling AP in KVM.

So I think for now we are fine. Later, this might be tricky to check but
not impossible.

Maybe we are applying the wrong semantics to this feature. The
premise for this feature was to control the setting of ECA.28.
It grew beyond this premise because of observations related to
future considerations about emulation and full virtualization (i.e.,
the things Pierre mentioned above). Instead of this feature
indicating AP facilities are installed on the guest, it might
behoove us to return to its original intended purpose which was
to indicate that AP instructions executed by the guest are
interpreted by HW. In this case, we can resume setting it in
the vcpu setup like it was in the earlier patch series.



Regards,

Pierre









[Qemu-devel] [PATCH v3 1/2] target/arm: Add a core count property

2018-03-02 Thread Alistair Francis
The cortex A53 TRM specifies that bits 24 and 25 of the L2CTLR register
specify the number of cores in the processor, not the total number of
cores in the sytem. To report this correctly on machines with multiple
CPU clusters (ARM's big.LITTLE or Xilinx's ZynqMP) we need to allow
the machine to overwrite this value. To do this let's add an optional
property.

Signed-off-by: Alistair Francis 
---
V3:
 - Fix Linux user compile failure
V2:
 - Fix commit message and title.
 - Move the core_count default setting logic to the arm_cpu_realize()
   function.

 target/arm/cpu.h   | 5 +
 target/arm/cpu.c   | 6 ++
 target/arm/cpu64.c | 6 --
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 8dd6b788df..3fa8fdad21 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -745,6 +745,11 @@ struct ARMCPU {
 /* Uniprocessor system with MP extensions */
 bool mp_is_up;
 
+/* Specify the number of cores in this CPU cluster. Used for the L2CTLR
+ * register.
+ */
+int32_t core_count;
+
 /* The instance init functions for implementation-specific subclasses
  * set these fields to specify the implementation-dependent values of
  * various constant registers and reset values of non-constant
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 6b77aaa445..3e4e9f1873 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -939,6 +939,11 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
 cs->num_ases = 1;
 }
 cpu_address_space_init(cs, ARMASIdx_NS, "cpu-memory", cs->memory);
+
+/* No core_count specified, default to smp_cpus. */
+if (cpu->core_count == -1) {
+cpu->core_count = smp_cpus;
+}
 #endif
 
 qemu_init_vcpu(cs);
@@ -1765,6 +1770,7 @@ static Property arm_cpu_properties[] = {
 DEFINE_PROP_UINT64("mp-affinity", ARMCPU,
 mp_affinity, ARM64_AFFINITY_INVALID),
 DEFINE_PROP_INT32("node-id", ARMCPU, node_id, CPU_UNSET_NUMA_NODE_ID),
+DEFINE_PROP_INT32("core-count", ARMCPU, core_count, -1),
 DEFINE_PROP_END_OF_LIST()
 };
 
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 4228713b19..dd9ba973f7 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -42,8 +42,10 @@ static inline void unset_feature(CPUARMState *env, int 
feature)
 #ifndef CONFIG_USER_ONLY
 static uint64_t a57_a53_l2ctlr_read(CPUARMState *env, const ARMCPRegInfo *ri)
 {
-/* Number of processors is in [25:24]; otherwise we RAZ */
-return (smp_cpus - 1) << 24;
+ARMCPU *cpu = arm_env_get_cpu(env);
+
+/* Number of cores is in [25:24]; otherwise we RAZ */
+return (cpu->core_count - 1) << 24;
 }
 #endif
 
-- 
2.14.1




[Qemu-devel] [PULL v4 23/30] qapi: Generate separate .h, .c for each module

2018-03-02 Thread Eric Blake
From: Markus Armbruster 

Our qapi-schema.json is composed of modules connected by include
directives, but the generated code is monolithic all the same: one
qapi-types.h with all the types, one qapi-visit.h with all the
visitors, and so forth.  These monolithic headers get included all
over the place.  In my "build everything" tree, adding a QAPI type
recompiles about 4800 out of 5100 objects.

We wouldn't write such monolithic headers by hand.  It stands to
reason that we shouldn't generate them, either.

Split up generated qapi-types.h to mirror the schema's modular
structure: one header per module.  Name the main module's header
qapi-types.h, and sub-module D/B.json's header D/qapi-types-B.h.

Mirror the schema's includes in the headers, so that qapi-types.h gets
you everything exactly as before.  If you need less, you can include
one or more of the sub-module headers.  To be exploited shortly.

Split up qapi-types.c, qapi-visit.h, qapi-visit.c, qmp-commands.h,
qmp-commands.c, qapi-event.h, qapi-event.c the same way.
qmp-introspect.h, qmp-introspect.c and qapi.texi remain monolithic.

The split of qmp-commands.c duplicates static helper function
qmp_marshal_output_str() in qapi-commands-char.c and
qapi-commands-misc.c.  This happens when commands returning the same
type occur in multiple modules.  Not worth avoiding.

Since I'm going to rename qapi-event.[ch] to qapi-events.[ch], and
qmp-commands.[ch] to qapi-commands.[ch], name the shards that way
already, to reduce churn.  This requires temporary hacks in
commands.py and events.py.  Similarly, c_name() must temporarily
be taught to munge '/' in common.py.  They'll go away with the rename.

Signed-off-by: Markus Armbruster 
Message-Id: <20180211093607.27351-23-arm...@redhat.com>
Reviewed-by: Eric Blake 
[eblake: declare a dummy variable in each .c file, to shut up OSX
toolchain warnings about empty .o files, including hacking c_name()]
Signed-off-by: Eric Blake 
---
 Makefile | 120 +++
 Makefile.objs|  65 -
 scripts/qapi/commands.py |  35 +-
 scripts/qapi/common.py   |  33 +++--
 scripts/qapi/events.py   |  19 ++--
 .gitignore   |  60 
 6 files changed, 310 insertions(+), 22 deletions(-)

diff --git a/Makefile b/Makefile
index 494ae382794..b12fcd5d8ff 100644
--- a/Makefile
+++ b/Makefile
@@ -92,10 +92,70 @@ include $(SRC_PATH)/rules.mak
 GENERATED_FILES = qemu-version.h config-host.h qemu-options.def
 GENERATED_FILES += qapi-builtin-types.h qapi-builtin-types.c
 GENERATED_FILES += qapi-types.h qapi-types.c
+GENERATED_FILES += qapi/qapi-types-block-core.h qapi/qapi-types-block-core.c
+GENERATED_FILES += qapi/qapi-types-block.h qapi/qapi-types-block.c
+GENERATED_FILES += qapi/qapi-types-char.h qapi/qapi-types-char.c
+GENERATED_FILES += qapi/qapi-types-common.h qapi/qapi-types-common.c
+GENERATED_FILES += qapi/qapi-types-crypto.h qapi/qapi-types-crypto.c
+GENERATED_FILES += qapi/qapi-types-introspect.h qapi/qapi-types-introspect.c
+GENERATED_FILES += qapi/qapi-types-migration.h qapi/qapi-types-migration.c
+GENERATED_FILES += qapi/qapi-types-net.h qapi/qapi-types-net.c
+GENERATED_FILES += qapi/qapi-types-rocker.h qapi/qapi-types-rocker.c
+GENERATED_FILES += qapi/qapi-types-run-state.h qapi/qapi-types-run-state.c
+GENERATED_FILES += qapi/qapi-types-sockets.h qapi/qapi-types-sockets.c
+GENERATED_FILES += qapi/qapi-types-tpm.h qapi/qapi-types-tpm.c
+GENERATED_FILES += qapi/qapi-types-trace.h qapi/qapi-types-trace.c
+GENERATED_FILES += qapi/qapi-types-transaction.h qapi/qapi-types-transaction.c
+GENERATED_FILES += qapi/qapi-types-ui.h qapi/qapi-types-ui.c
 GENERATED_FILES += qapi-builtin-visit.h qapi-builtin-visit.c
 GENERATED_FILES += qapi-visit.h qapi-visit.c
+GENERATED_FILES += qapi/qapi-visit-block-core.h qapi/qapi-visit-block-core.c
+GENERATED_FILES += qapi/qapi-visit-block.h qapi/qapi-visit-block.c
+GENERATED_FILES += qapi/qapi-visit-char.h qapi/qapi-visit-char.c
+GENERATED_FILES += qapi/qapi-visit-common.h qapi/qapi-visit-common.c
+GENERATED_FILES += qapi/qapi-visit-crypto.h qapi/qapi-visit-crypto.c
+GENERATED_FILES += qapi/qapi-visit-introspect.h qapi/qapi-visit-introspect.c
+GENERATED_FILES += qapi/qapi-visit-migration.h qapi/qapi-visit-migration.c
+GENERATED_FILES += qapi/qapi-visit-net.h qapi/qapi-visit-net.c
+GENERATED_FILES += qapi/qapi-visit-rocker.h qapi/qapi-visit-rocker.c
+GENERATED_FILES += qapi/qapi-visit-run-state.h qapi/qapi-visit-run-state.c
+GENERATED_FILES += qapi/qapi-visit-sockets.h qapi/qapi-visit-sockets.c
+GENERATED_FILES += qapi/qapi-visit-tpm.h qapi/qapi-visit-tpm.c
+GENERATED_FILES += qapi/qapi-visit-trace.h qapi/qapi-visit-trace.c
+GENERATED_FILES += qapi/qapi-visit-transaction.h qapi/qapi-visit-transaction.c
+GENERATED_FILES += qapi/qapi-visit-ui.h qapi/qapi-visit-ui.c
 GENERATED_FILES += 

[Qemu-devel] [PULL v4 00/30] QAPI patches for 2018-03-01

2018-03-02 Thread Eric Blake
The following changes since commit 136c67e07869227b21b3f627316e03679ce7b738:

  Merge remote-tracking branch 
'remotes/bkoppelmann/tags/pull-tricore-2018-03-02' into staging (2018-03-02 
16:56:20 +)

are available in the Git repository at:

  git://repo.or.cz/qemu/ericb.git tags/pull-qapi-2018-03-01-v4

for you to fetch changes up to 418b1d0ae3a2cc992659f626a2a3f11944e0b259:

  qapi: Don't create useless directory qapi-generated (2018-03-02 13:48:26 
-0600)

v4: another attempt at silencing OSX warnings on empty .o [Peter]
(sending just the changed patches)


qapi patches for 2018-03-01

- Markus Armbruster: Modularize generated QAPI code


Eric Blake (1):
  watchdog: Consolidate QAPI into single file

Markus Armbruster (29):
  Include qapi/qmp/qerror.h exactly where needed
  qapi: Streamline boilerplate comment generation
  qapi: Generate up-to-date copyright notice
  qapi: Rename variable holding the QAPISchemaGenFOOVisitor
  qapi: New classes QAPIGenC, QAPIGenH, QAPIGenDoc
  qapi: Reduce use of global variables in generators some
  qapi: Turn generators into modules
  qapi-gen: New common driver for code and doc generators
  qapi-gen: Convert from getopt to argparse
  qapi: Touch generated files only when they change
  qapi: Improve include file name reporting in error messages
  qapi/common: Eliminate QAPISchema.exprs
  qapi: Lift error reporting from QAPISchema.__init__() to callers
  qapi: Concentrate QAPISchemaParser.exprs updates in .__init__()
  qapi: Record 'include' directives in parse tree
  qapi: Generate in source order
  qapi: Record 'include' directives in intermediate representation
  qapi: Rename generated qmp-marshal.c to qmp-commands.c
  qapi: Make code-generating visitors use QAPIGen more
  qapi/types qapi/visit: Generate built-in stuff into separate files
  qapi/common: Fix guardname() for funny filenames
  qapi: Generate separate .h, .c for each module
  Include less of the generated modular QAPI headers
  qapi: Empty out qapi-schema.json
  docs/devel/writing-qmp-commands: Update for modular QAPI
  docs: Correct outdated information on QAPI
  qapi: Move qapi-schema.json to qapi/, rename generated files
  Fix up dangling references to qmp-commands.* in comment and doc
  qapi: Don't create useless directory qapi-generated

 docs/devel/qapi-code-gen.txt   | 124 ---
 docs/devel/writing-qmp-commands.txt|  39 +--
 docs/interop/qmp-intro.txt |   3 +-
 docs/xen-save-devices-state.txt|   3 +-
 tests/qapi-schema/doc-good.texi|   3 +-
 configure  |   1 -
 Makefile   | 233 +
 Makefile.objs  |  80 -
 qapi-schema.json => qapi/misc.json | 105 +-
 qapi/qapi-schema.json  |  95 ++
 qapi/run-state.json|   9 +
 include/qapi/visitor.h |   2 +-
 scripts/qapi-gen.py|  57 
 scripts/qapi/__init__.py   |   0
 scripts/{qapi-commands.py => qapi/commands.py} | 155 -
 scripts/{qapi.py => qapi/common.py}| 362 +
 scripts/{qapi2texi.py => qapi/doc.py}  |  92 +++---
 scripts/{qapi-event.py => qapi/events.py}  | 128 +++-
 scripts/{qapi-introspect.py => qapi/introspect.py} | 123 +++
 scripts/{qapi-types.py => qapi/types.py}   | 185 ---
 scripts/{qapi-visit.py => qapi/visit.py}   | 189 ---
 crypto/cipherpriv.h|   2 +-
 include/block/block.h  |   2 +-
 include/block/dirty-bitmap.h   |   2 +-
 include/block/nbd.h|   2 +-
 include/chardev/char.h |   1 +
 include/crypto/cipher.h|   2 +-
 include/crypto/hash.h  |   2 +-
 include/crypto/hmac.h  |   2 +-
 include/crypto/secret.h|   1 +
 include/crypto/tlscreds.h  |   1 +
 include/hw/block/block.h   |   2 +-
 include/hw/block/fdc.h |   2 +-
 include/hw/ppc/spapr_drc.h |   1 +
 include/hw/qdev-properties.h   |   2 +
 include/io/dns-resolver.h  |   1 +
 include/migration/colo.h   |   2 +-
 include/migration/failover.h   |   2 +-
 include/migration/global_state.h   |   1 +
 

Re: [Qemu-devel] [PATCH 4/4] virtio-net: add linkspeed and duplex settings to virtio-net

2018-03-02 Thread Michael S. Tsirkin
On Fri, Mar 02, 2018 at 11:59:00AM -0500, Jason Baron wrote:
> On 03/02/2018 02:14 AM, Jason Wang wrote:
> > 
> > 
> > On 2018年03月02日 11:46, Jason Baron wrote:
> >> Although linkspeed and duplex can be set in a linux guest via 'ethtool
> >> -s',
> >> this requires custom ethtool commands for virtio-net by default.
> >>
> >> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
> >> the hypervisor to export a linkspeed and duplex setting. The user can
> >> subsequently overwrite it later if desired via: 'ethtool -s'.
> >>
> >> Linkspeed and duplex settings can be set as:
> >> '-device virtio-net,speed=1,duplex=full'
> > 
> > I was thinking whether or not it's better to decide the duplex by the
> > type of backends.
> > 
> > E.g userspace and vhost-kernel implement a in fact half duplex. But dpdk
> > implement a full duplex.
> 
> Interesting - could this be derived only from the backend 'type'. IE:
> NET_CLIENT_DRIVER_TAP, NET_CLIENT_DRIVER_VHOST_USER...
> 
> 
> I was also thinking this could be specified as 'duplex=backend', in
> addition to the proposed 'duplex=full' or 'duplex=half'?
> 
> Thanks,
> 
> -Jason

I'd say it would make more sense to teach backends to obey what's
specified by the user. E.g. if vhost gets a duplex config,
create two threads.

But I think all that's for future, we can just fake it for
now - the current uses don't seem to particularly care about whether
virtio actually is or isn't a duplex.



> > 
> > Thanks
> > 
> >>
> >> where speed is [0...INT_MAX], and duplex is ["half"|"full"].
> >>
> >> Signed-off-by: Jason Baron
> >> Cc: "Michael S. Tsirkin"
> >> Cc: Jason Wang
> >> Cc:virtio-...@lists.oasis-open.org
> >> ---
> > 



[Qemu-devel] [Bug 1673976] Re: linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert)

2018-03-02 Thread Éric Hoffman
Ok, yes you are right...

I have looked a bit more on the source code, and indeed, I think
understand the issue with the VFORK with QEMU.  Please correct me if I'm
wrong...

- In the syscall trap handler, it has to use the fork() function to emulate the 
vfork() due to restriction of the vfork() function (as QEMU must continue to 
control the flow of instruction past the call to vfork(), and do a lot more 
things in the child thread before ending up performing a execve() or _exit())
- Also, it can not do a wait() for the emulated child, as this child will 
continue to exist even after it calls execve(), so the parent would stall.
- Then, I taught about doing condition signalling, like waiting for a pthread 
condition signal that the child would send once it come to the point of 
performing the _exit() or execve(), but the child would, for example, need to 
know if execve() was successful, or otherwise the child would continue and set 
an error flag and then call _exit().  We do need that error flag before 
continuing the execution on the parent.  So we can not signal back to the 
parent that the 'emulated vfork' is OK before calling execve(), but we can not 
wait after execve() because if the call is successful, there is no return from 
that function, and code goes outside the control of QEMU.

So, I taught of an idea...  What if, in the TARGET_NR_clone syscall trap, when 
we are called upon a CLONE_VFORK, we do:
- Do a regular fork, as it's currently done, with CLONE_VM flag (so the child 
share the same memory as the parent).  However, we also set a state flag that 
we are in this 'vfork emulation' mode just before the fork (more on that 
bellow...).
- Let the parent wait for the child to terminate (again, more on that 
bellow...).
- Let the child return normally and continue execution, as if the parent was 
waiting.

Then, eventually the child will eventually either end up in the 
TARGET_NR_execve or __NR_exit_group syscall trap.  At which point:
- The child check if it is in 'vfork emulation' mode.  If not, then there's 
nothing special, just continue the way the code is currently written.  If the 
flag is set, then follow on with the steps bellow...
- The child set a flag that tell where it is (TARGET_NR_execve or 
__NR_exit_group, and the arguments passed to that syscall), and that everything 
is ok (it has not simply died meanwhile).
- The child terminate, which resume the parent's execution.

The parent then:
- Clear the 'vfork emulation' flag.
- Look at where the child left (was it performing TARGET_NR_execve or 
__NR_exit_group syscall?  What was the arguments passed to the syscall?).  This 
is pretty easy since the child was writing to the parent's memory space the 
whole time (CLONE_VM).  The parent could even use a flag allocated on it's 
stack before the fork(), since the child will have run with it's own stack 
during that time (so the parent stack is still intact).
- Now that we know what the child wanted to do (what syscall and which 
parameters), the parent (which at his point has no more 'leftover' child), can 
then do a *real* vfork, or otherwise return the proper error code.

It's a bit far fetched, and I'm far from implying that I know much about
QEMU, but this is an idea :-)  Sound like it's pretty straightforward
though.  Basically we just wait for the code between the _clone()
function and the _execve/_exit function to complete, at which point we
take action and we are in measure to assess the status code (and do the
real vfork).

Regards,
Eric

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

Title:
  linux-user clone() can't handle glibc posix_spawn() (causes locale-gen
  to assert)

Status in QEMU:
  New

Bug description:
  I'm running a command (locale-gen) inside of an armv7h chroot mounted
  on my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the
  chroot file system and I get a core dump.

  locale-gen
  Generating locales...
    en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: 
__spawnix: Assertion `ec >= 0' failed.
  qemu: uncaught target signal 6 (Aborted) - core dumped
  /usr/bin/locale-gen: line 41:34 Aborted (core dumped) 
localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale

  I've done this same thing successfully for years, but this breakage
  has appeared some time in the last 3 or so months. Possibly with the
  update to qemu version 2.8.

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



Re: [Qemu-devel] [PULL 12/51] build-sys: compile with -Og or -O1 when --enable-debug

2018-03-02 Thread Peter Maydell
On 16 January 2018 at 14:16, Paolo Bonzini  wrote:
> From: Marc-André Lureau 
>
> When --enable-debug is turned on, configure doesn't set -O level, and
> uses default compiler -O0 level, which is slow.
>
> Instead, use -Og if supported by the compiler (optimize debugging
> experience), or -O1 (keeps code somewhat debuggable and works around
> compiler bugs).

This gives me a noticeably worse debug experience (using -Og),
because gdb shows a lot more "" variables and
function arguments. (I've been mildly irritated by this for
the last few weeks and only just figured out why this was
happening.)

Can we go back to the previous behaviour, please ? I don't
care if the build is slow if I'm debugging, but I really do
care that I don't have my variables and arguments all
optimised away by the compiler so I can't tell what's going on.

thanks
-- PMM



[Qemu-devel] [PULL 15/37] sheepdog: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the sheepdog driver accordingly.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Reviewed-by: Jeff Cody 
Signed-off-by: Kevin Wolf 
---
 block/sheepdog.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/block/sheepdog.c b/block/sheepdog.c
index ac02b10fe0..3c3becf94d 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -3004,19 +3004,19 @@ static coroutine_fn int sd_co_pdiscard(BlockDriverState 
*bs, int64_t offset,
 return acb.ret;
 }
 
-static coroutine_fn int64_t
-sd_co_get_block_status(BlockDriverState *bs, int64_t sector_num, int 
nb_sectors,
-   int *pnum, BlockDriverState **file)
+static coroutine_fn int
+sd_co_block_status(BlockDriverState *bs, bool want_zero, int64_t offset,
+   int64_t bytes, int64_t *pnum, int64_t *map,
+   BlockDriverState **file)
 {
 BDRVSheepdogState *s = bs->opaque;
 SheepdogInode *inode = >inode;
 uint32_t object_size = (UINT32_C(1) << inode->block_size_shift);
-uint64_t offset = sector_num * BDRV_SECTOR_SIZE;
 unsigned long start = offset / object_size,
-  end = DIV_ROUND_UP((sector_num + nb_sectors) *
- BDRV_SECTOR_SIZE, object_size);
+  end = DIV_ROUND_UP(offset + bytes, object_size);
 unsigned long idx;
-int64_t ret = BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID | offset;
+*map = offset;
+int ret = BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID;
 
 for (idx = start; idx < end; idx++) {
 if (inode->data_vdi_id[idx] == 0) {
@@ -3033,9 +3033,9 @@ sd_co_get_block_status(BlockDriverState *bs, int64_t 
sector_num, int nb_sectors,
 }
 }
 
-*pnum = (idx - start) * object_size / BDRV_SECTOR_SIZE;
-if (*pnum > nb_sectors) {
-*pnum = nb_sectors;
+*pnum = (idx - start) * object_size;
+if (*pnum > bytes) {
+*pnum = bytes;
 }
 if (ret > 0 && ret & BDRV_BLOCK_OFFSET_VALID) {
 *file = bs;
@@ -3113,7 +3113,7 @@ static BlockDriver bdrv_sheepdog = {
 .bdrv_co_writev   = sd_co_writev,
 .bdrv_co_flush_to_disk= sd_co_flush_to_disk,
 .bdrv_co_pdiscard = sd_co_pdiscard,
-.bdrv_co_get_block_status = sd_co_get_block_status,
+.bdrv_co_block_status = sd_co_block_status,
 
 .bdrv_snapshot_create = sd_snapshot_create,
 .bdrv_snapshot_goto   = sd_snapshot_goto,
@@ -3149,7 +3149,7 @@ static BlockDriver bdrv_sheepdog_tcp = {
 .bdrv_co_writev   = sd_co_writev,
 .bdrv_co_flush_to_disk= sd_co_flush_to_disk,
 .bdrv_co_pdiscard = sd_co_pdiscard,
-.bdrv_co_get_block_status = sd_co_get_block_status,
+.bdrv_co_block_status = sd_co_block_status,
 
 .bdrv_snapshot_create = sd_snapshot_create,
 .bdrv_snapshot_goto   = sd_snapshot_goto,
@@ -3185,7 +3185,7 @@ static BlockDriver bdrv_sheepdog_unix = {
 .bdrv_co_writev   = sd_co_writev,
 .bdrv_co_flush_to_disk= sd_co_flush_to_disk,
 .bdrv_co_pdiscard = sd_co_pdiscard,
-.bdrv_co_get_block_status = sd_co_get_block_status,
+.bdrv_co_block_status = sd_co_block_status,
 
 .bdrv_snapshot_create = sd_snapshot_create,
 .bdrv_snapshot_goto   = sd_snapshot_goto,
-- 
2.13.6




[Qemu-devel] [PULL 14/37] raw: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the raw driver accordingly.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/raw-format.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/block/raw-format.c b/block/raw-format.c
index ab552c0954..830243a8e4 100644
--- a/block/raw-format.c
+++ b/block/raw-format.c
@@ -250,17 +250,17 @@ fail:
 return ret;
 }
 
-static int64_t coroutine_fn raw_co_get_block_status(BlockDriverState *bs,
-int64_t sector_num,
-int nb_sectors, int *pnum,
+static int coroutine_fn raw_co_block_status(BlockDriverState *bs,
+bool want_zero, int64_t offset,
+int64_t bytes, int64_t *pnum,
+int64_t *map,
 BlockDriverState **file)
 {
 BDRVRawState *s = bs->opaque;
-*pnum = nb_sectors;
+*pnum = bytes;
 *file = bs->file->bs;
-sector_num += s->offset / BDRV_SECTOR_SIZE;
-return BDRV_BLOCK_RAW | BDRV_BLOCK_OFFSET_VALID |
-   (sector_num << BDRV_SECTOR_BITS);
+*map = offset + s->offset;
+return BDRV_BLOCK_RAW | BDRV_BLOCK_OFFSET_VALID;
 }
 
 static int coroutine_fn raw_co_pwrite_zeroes(BlockDriverState *bs,
@@ -496,7 +496,7 @@ BlockDriver bdrv_raw = {
 .bdrv_co_pwritev  = _co_pwritev,
 .bdrv_co_pwrite_zeroes = _co_pwrite_zeroes,
 .bdrv_co_pdiscard = _co_pdiscard,
-.bdrv_co_get_block_status = _co_get_block_status,
+.bdrv_co_block_status = _co_block_status,
 .bdrv_truncate= _truncate,
 .bdrv_getlength   = _getlength,
 .has_variable_length  = true,
-- 
2.13.6




[Qemu-devel] [PULL 09/37] null: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the null driver accordingly.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/null.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/block/null.c b/block/null.c
index 214d394fff..806a8631e4 100644
--- a/block/null.c
+++ b/block/null.c
@@ -223,22 +223,23 @@ static int null_reopen_prepare(BDRVReopenState 
*reopen_state,
 return 0;
 }
 
-static int64_t coroutine_fn null_co_get_block_status(BlockDriverState *bs,
- int64_t sector_num,
- int nb_sectors, int *pnum,
- BlockDriverState **file)
+static int coroutine_fn null_co_block_status(BlockDriverState *bs,
+ bool want_zero, int64_t offset,
+ int64_t bytes, int64_t *pnum,
+ int64_t *map,
+ BlockDriverState **file)
 {
 BDRVNullState *s = bs->opaque;
-off_t start = sector_num * BDRV_SECTOR_SIZE;
+int ret = BDRV_BLOCK_OFFSET_VALID;
 
-*pnum = nb_sectors;
+*pnum = bytes;
+*map = offset;
 *file = bs;
 
 if (s->read_zeroes) {
-return BDRV_BLOCK_OFFSET_VALID | start | BDRV_BLOCK_ZERO;
-} else {
-return BDRV_BLOCK_OFFSET_VALID | start;
+ret |= BDRV_BLOCK_ZERO;
 }
+return ret;
 }
 
 static void null_refresh_filename(BlockDriverState *bs, QDict *opts)
@@ -270,7 +271,7 @@ static BlockDriver bdrv_null_co = {
 .bdrv_co_flush_to_disk  = null_co_flush,
 .bdrv_reopen_prepare= null_reopen_prepare,
 
-.bdrv_co_get_block_status   = null_co_get_block_status,
+.bdrv_co_block_status   = null_co_block_status,
 
 .bdrv_refresh_filename  = null_refresh_filename,
 };
@@ -290,7 +291,7 @@ static BlockDriver bdrv_null_aio = {
 .bdrv_aio_flush = null_aio_flush,
 .bdrv_reopen_prepare= null_reopen_prepare,
 
-.bdrv_co_get_block_status   = null_co_get_block_status,
+.bdrv_co_block_status   = null_co_block_status,
 
 .bdrv_refresh_filename  = null_refresh_filename,
 };
-- 
2.13.6




[Qemu-devel] [PULL 19/37] vpc: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the vpc driver accordingly.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/vpc.c | 45 +++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/block/vpc.c b/block/vpc.c
index cfa5144e86..fba4492fd7 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -706,53 +706,54 @@ fail:
 return ret;
 }
 
-static int64_t coroutine_fn vpc_co_get_block_status(BlockDriverState *bs,
-int64_t sector_num, int nb_sectors, int *pnum, BlockDriverState **file)
+static int coroutine_fn vpc_co_block_status(BlockDriverState *bs,
+bool want_zero,
+int64_t offset, int64_t bytes,
+int64_t *pnum, int64_t *map,
+BlockDriverState **file)
 {
 BDRVVPCState *s = bs->opaque;
 VHDFooter *footer = (VHDFooter*) s->footer_buf;
-int64_t start, offset;
+int64_t image_offset;
 bool allocated;
-int64_t ret;
-int n;
+int ret;
+int64_t n;
 
 if (be32_to_cpu(footer->type) == VHD_FIXED) {
-*pnum = nb_sectors;
+*pnum = bytes;
+*map = offset;
 *file = bs->file->bs;
-return BDRV_BLOCK_RAW | BDRV_BLOCK_OFFSET_VALID |
-   (sector_num << BDRV_SECTOR_BITS);
+return BDRV_BLOCK_RAW | BDRV_BLOCK_OFFSET_VALID;
 }
 
 qemu_co_mutex_lock(>lock);
 
-offset = get_image_offset(bs, sector_num << BDRV_SECTOR_BITS, false, NULL);
-start = offset;
-allocated = (offset != -1);
+image_offset = get_image_offset(bs, offset, false, NULL);
+allocated = (image_offset != -1);
 *pnum = 0;
 ret = 0;
 
 do {
 /* All sectors in a block are contiguous (without using the bitmap) */
-n = ROUND_UP(sector_num + 1, s->block_size / BDRV_SECTOR_SIZE)
-  - sector_num;
-n = MIN(n, nb_sectors);
+n = ROUND_UP(offset + 1, s->block_size) - offset;
+n = MIN(n, bytes);
 
 *pnum += n;
-sector_num += n;
-nb_sectors -= n;
+offset += n;
+bytes -= n;
 /* *pnum can't be greater than one block for allocated
  * sectors since there is always a bitmap in between. */
 if (allocated) {
 *file = bs->file->bs;
-ret = BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID | start;
+*map = image_offset;
+ret = BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID;
 break;
 }
-if (nb_sectors == 0) {
+if (bytes == 0) {
 break;
 }
-offset = get_image_offset(bs, sector_num << BDRV_SECTOR_BITS, false,
-  NULL);
-} while (offset == -1);
+image_offset = get_image_offset(bs, offset, false, NULL);
+} while (image_offset == -1);
 
 qemu_co_mutex_unlock(>lock);
 return ret;
@@ -1098,7 +1099,7 @@ static BlockDriver bdrv_vpc = {
 
 .bdrv_co_preadv = vpc_co_preadv,
 .bdrv_co_pwritev= vpc_co_pwritev,
-.bdrv_co_get_block_status   = vpc_co_get_block_status,
+.bdrv_co_block_status   = vpc_co_block_status,
 
 .bdrv_get_info  = vpc_get_info,
 
-- 
2.13.6




[Qemu-devel] [PULL 23/37] iotest 033: add misaligned write-zeroes test via truncate

2018-03-02 Thread Kevin Wolf
From: Anton Nefedov 

This new test case only makes sense for qcow2 while iotest 033 is generic;
however it matches the test purpose perfectly and also 033 contains those
do_test() tricks to pass the alignment, which won't look nice being
duplicated in other tests or moved to the common code.

Signed-off-by: Anton Nefedov 
Signed-off-by: Kevin Wolf 
---
 tests/qemu-iotests/033 | 29 +
 tests/qemu-iotests/033.out | 13 +
 2 files changed, 42 insertions(+)

diff --git a/tests/qemu-iotests/033 b/tests/qemu-iotests/033
index 2cdfd1397a..a1d8357331 100755
--- a/tests/qemu-iotests/033
+++ b/tests/qemu-iotests/033
@@ -64,6 +64,9 @@ do_test()
} | $QEMU_IO $IO_EXTRA_ARGS
 }
 
+echo
+echo "=== Test aligned and misaligned write zeroes operations ==="
+
 for write_zero_cmd in "write -z" "aio_write -z"; do
 for align in 512 4k; do
echo
@@ -102,7 +105,33 @@ for align in 512 4k; do
 done
 done
 
+
+# Trigger truncate that would shrink qcow2 L1 table, which is done by
+#   clearing one entry (8 bytes) with bdrv_co_pwrite_zeroes()
+
+echo
+echo "=== Test misaligned write zeroes via truncate ==="
+echo
+
+# any size will do, but the smaller the size the smaller the required image
+CLUSTER_SIZE=$((4 * 1024))
+L2_COVERAGE=$(($CLUSTER_SIZE * $CLUSTER_SIZE / 8))
+_make_test_img $(($L2_COVERAGE * 2))
+
+do_test 512 "write -P 1 0 0x200" "$TEST_IMG" | _filter_qemu_io
+# next L2 table
+do_test 512 "write -P 1 $L2_COVERAGE 0x200" "$TEST_IMG" | _filter_qemu_io
+
+# only interested in qcow2 here; also other formats might respond with
+#  "not supported" error message
+if [ $IMGFMT = "qcow2" ]; then
+do_test 512 "truncate $L2_COVERAGE" "$TEST_IMG" | _filter_qemu_io
+fi
+
+do_test 512 "read -P 1 0 0x200" "$TEST_IMG" | _filter_qemu_io
+
 # success, all done
+echo
 echo "*** done"
 rm -f $seq.full
 status=0
diff --git a/tests/qemu-iotests/033.out b/tests/qemu-iotests/033.out
index 95929eff70..9683f6b290 100644
--- a/tests/qemu-iotests/033.out
+++ b/tests/qemu-iotests/033.out
@@ -1,6 +1,8 @@
 QA output created by 033
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
 
+=== Test aligned and misaligned write zeroes operations ===
+
 == preparing image ==
 wrote 1024/1024 bytes at offset 512
 1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
@@ -164,4 +166,15 @@ read 512/512 bytes at offset 512
 read 3072/3072 bytes at offset 1024
 3 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 
+
+=== Test misaligned write zeroes via truncate ===
+
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=4194304
+wrote 512/512 bytes at offset 0
+512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 512/512 bytes at offset 2097152
+512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+read 512/512 bytes at offset 0
+512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
 *** done
-- 
2.13.6




[Qemu-devel] [PULL 16/37] vdi: Avoid bitrot of debugging code

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

Rework the debug define so that we always get -Wformat checking,
even when debugging is disabled.

Signed-off-by: Eric Blake 
Reviewed-by: Stefan Weil 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/vdi.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/block/vdi.c b/block/vdi.c
index fc1c614cb1..32b1763cde 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -87,12 +87,18 @@
 #define DEFAULT_CLUSTER_SIZE (1 * MiB)
 
 #if defined(CONFIG_VDI_DEBUG)
-#define logout(fmt, ...) \
-fprintf(stderr, "vdi\t%-24s" fmt, __func__, ##__VA_ARGS__)
+#define VDI_DEBUG 1
 #else
-#define logout(fmt, ...) ((void)0)
+#define VDI_DEBUG 0
 #endif
 
+#define logout(fmt, ...) \
+do {\
+if (VDI_DEBUG) {\
+fprintf(stderr, "vdi\t%-24s" fmt, __func__, ##__VA_ARGS__); \
+}   \
+} while (0)
+
 /* Image signature. */
 #define VDI_SIGNATURE 0xbeda107f
 
-- 
2.13.6




[Qemu-devel] [PULL 25/37] docs: document how to use the l2-cache-entry-size parameter

2018-03-02 Thread Kevin Wolf
From: Alberto Garcia 

This patch updates docs/qcow2-cache.txt explaining how to use the new
l2-cache-entry-size parameter.

Here's a more detailed technical description of this feature:

   https://lists.gnu.org/archive/html/qemu-block/2017-09/msg00635.html

And here are some performance numbers:

   https://lists.gnu.org/archive/html/qemu-block/2017-12/msg00507.html

Signed-off-by: Alberto Garcia 
Reviewed-by: Eric Blake 
Signed-off-by: Kevin Wolf 
---
 docs/qcow2-cache.txt | 46 +++---
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/docs/qcow2-cache.txt b/docs/qcow2-cache.txt
index b0571de4b8..170191a242 100644
--- a/docs/qcow2-cache.txt
+++ b/docs/qcow2-cache.txt
@@ -1,6 +1,6 @@
 qcow2 L2/refcount cache configuration
 =
-Copyright (C) 2015 Igalia, S.L.
+Copyright (C) 2015, 2018 Igalia, S.L.
 Author: Alberto Garcia 
 
 This work is licensed under the terms of the GNU GPL, version 2 or
@@ -118,8 +118,8 @@ There are three options available, and all of them take 
bytes:
 
 There are two things that need to be taken into account:
 
- - Both caches must have a size that is a multiple of the cluster
-   size.
+ - Both caches must have a size that is a multiple of the cluster size
+   (or the cache entry size: see "Using smaller cache sizes" below).
 
  - If you only set one of the options above, QEMU will automatically
adjust the others so that the L2 cache is 4 times bigger than the
@@ -143,6 +143,46 @@ much less often than the L2 cache, so it's perfectly 
reasonable to
 keep it small.
 
 
+Using smaller cache entries
+---
+The qcow2 L2 cache stores complete tables by default. This means that
+if QEMU needs an entry from an L2 table then the whole table is read
+from disk and is kept in the cache. If the cache is full then a
+complete table needs to be evicted first.
+
+This can be inefficient with large cluster sizes since it results in
+more disk I/O and wastes more cache memory.
+
+Since QEMU 2.12 you can change the size of the L2 cache entry and make
+it smaller than the cluster size. This can be configured using the
+"l2-cache-entry-size" parameter:
+
+   -drive file=hd.qcow2,l2-cache-size=2097152,l2-cache-entry-size=4096
+
+Some things to take into account:
+
+ - The L2 cache entry size has the same restrictions as the cluster
+   size (power of two, at least 512 bytes).
+
+ - Smaller entry sizes generally improve the cache efficiency and make
+   disk I/O faster. This is particularly true with solid state drives
+   so it's a good idea to reduce the entry size in those cases. With
+   rotating hard drives the situation is a bit more complicated so you
+   should test it first and stay with the default size if unsure.
+
+ - Try different entry sizes to see which one gives faster performance
+   in your case. The block size of the host filesystem is generally a
+   good default (usually 4096 bytes in the case of ext4).
+
+ - Only the L2 cache can be configured this way. The refcount cache
+   always uses the cluster size as the entry size.
+
+ - If the L2 cache is big enough to hold all of the image's L2 tables
+   (as explained in the "Choosing the right cache sizes" section
+   earlier in this document) then none of this is necessary and you
+   can omit the "l2-cache-entry-size" parameter altogether.
+
+
 Reducing the memory usage
 -
 It is possible to clean unused cache entries in order to reduce the
-- 
2.13.6




[Qemu-devel] [PULL 30/37] Revert "IDE: Do not flush empty CDROM drives"

2018-03-02 Thread Kevin Wolf
From: Stefan Hajnoczi 

This reverts commit 4da97120d51a4383aa96d741a2b837f8c4bbcd0b.

blk_aio_flush() now handles the blk->root == NULL case, so we no longer
need this workaround.

Cc: John Snow 
Signed-off-by: Stefan Hajnoczi 
Reviewed-by: Eric Blake 
Signed-off-by: Kevin Wolf 
---
 hw/ide/core.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/hw/ide/core.c b/hw/ide/core.c
index 257b429381..139c843514 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1087,15 +1087,7 @@ static void ide_flush_cache(IDEState *s)
 s->status |= BUSY_STAT;
 ide_set_retry(s);
 block_acct_start(blk_get_stats(s->blk), >acct, 0, BLOCK_ACCT_FLUSH);
-
-if (blk_bs(s->blk)) {
-s->pio_aiocb = blk_aio_flush(s->blk, ide_flush_cb, s);
-} else {
-/* XXX blk_aio_flush() crashes when blk_bs(blk) is NULL, remove this
- * temporary workaround when blk_aio_*() functions handle NULL blk_bs.
- */
-ide_flush_cb(s, 0);
-}
+s->pio_aiocb = blk_aio_flush(s->blk, ide_flush_cb, s);
 }
 
 static void ide_cfata_metadata_inquiry(IDEState *s)
-- 
2.13.6




[Qemu-devel] [PULL 3/3] tcg: Add choose_vector_size

2018-03-02 Thread Richard Henderson
This unifies 5 copies of checks for supported vector size,
and in the process fixes a missing check in tcg_gen_gvec_2s.

This lead to an assertion failure for 64-bit vector multiply,
which is not available in the AVX instruction set.

Suggested-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 tcg/tcg-op-gvec.c | 438 --
 1 file changed, 259 insertions(+), 179 deletions(-)

diff --git a/tcg/tcg-op-gvec.c b/tcg/tcg-op-gvec.c
index bfe44bba81..22db1590d5 100644
--- a/tcg/tcg-op-gvec.c
+++ b/tcg/tcg-op-gvec.c
@@ -351,6 +351,42 @@ static void gen_dup_i64(unsigned vece, TCGv_i64 out, 
TCGv_i64 in)
 }
 }
 
+/* Select a supported vector type for implementing an operation on SIZE
+ * bytes.  If OP is 0, assume that the real operation to be performed is
+ * required by all backends.  Otherwise, make sure than OP can be performed
+ * on elements of size VECE in the selected type.  Do not select V64 if
+ * PREFER_I64 is true.  Return 0 if no vector type is selected.
+ */
+static TCGType choose_vector_type(TCGOpcode op, unsigned vece, uint32_t size,
+  bool prefer_i64)
+{
+if (TCG_TARGET_HAS_v256 && check_size_impl(size, 32)) {
+if (op == 0) {
+return TCG_TYPE_V256;
+}
+/* Recall that ARM SVE allows vector sizes that are not a
+ * power of 2, but always a multiple of 16.  The intent is
+ * that e.g. size == 80 would be expanded with 2x32 + 1x16.
+ * It is hard to imagine a case in which v256 is supported
+ * but v128 is not, but check anyway.
+ */
+if (tcg_can_emit_vec_op(op, TCG_TYPE_V256, vece)
+&& (size % 32 == 0
+|| tcg_can_emit_vec_op(op, TCG_TYPE_V128, vece))) {
+return TCG_TYPE_V256;
+}
+}
+if (TCG_TARGET_HAS_v128 && check_size_impl(size, 16)
+&& (op == 0 || tcg_can_emit_vec_op(op, TCG_TYPE_V128, vece))) {
+return TCG_TYPE_V128;
+}
+if (TCG_TARGET_HAS_v64 && !prefer_i64 && check_size_impl(size, 8)
+&& (op == 0 || tcg_can_emit_vec_op(op, TCG_TYPE_V64, vece))) {
+return TCG_TYPE_V64;
+}
+return 0;
+}
+
 /* Set OPRSZ bytes at DOFS to replications of IN_32, IN_64 or IN_C.
  * Only one of IN_32 or IN_64 may be set;
  * IN_C is used if IN_32 and IN_64 are unset.
@@ -376,19 +412,12 @@ static void do_dup(unsigned vece, uint32_t dofs, uint32_t 
oprsz,
 }
 }
 
-type = 0;
-if (TCG_TARGET_HAS_v256 && check_size_impl(oprsz, 32)) {
-type = TCG_TYPE_V256;
-} else if (TCG_TARGET_HAS_v128 && check_size_impl(oprsz, 16)) {
-type = TCG_TYPE_V128;
-} else if (TCG_TARGET_HAS_v64 && check_size_impl(oprsz, 8)
-   /* Prefer integer when 64-bit host and no variable dup.  */
-   && !(TCG_TARGET_REG_BITS == 64 && in_32 == NULL
-&& (in_64 == NULL || vece == MO_64))) {
-type = TCG_TYPE_V64;
-}
-
-/* Implement inline with a vector type, if possible.  */
+/* Implement inline with a vector type, if possible.
+ * Prefer integer when 64-bit host and no variable dup.
+ */
+type = choose_vector_type(0, vece, oprsz,
+  (TCG_TARGET_REG_BITS == 64 && in_32 == NULL
+   && (in_64 == NULL || vece == MO_64)));
 if (type != 0) {
 TCGv_vec t_vec = tcg_temp_new_vec(type);
 
@@ -414,21 +443,30 @@ static void do_dup(unsigned vece, uint32_t dofs, uint32_t 
oprsz,
 }
 
 i = 0;
-if (TCG_TARGET_HAS_v256) {
+switch (type) {
+case TCG_TYPE_V256:
+/* Recall that ARM SVE allows vector sizes that are not a
+ * power of 2, but always a multiple of 16.  The intent is
+ * that e.g. size == 80 would be expanded with 2x32 + 1x16.
+ */
 for (; i + 32 <= oprsz; i += 32) {
 tcg_gen_stl_vec(t_vec, cpu_env, dofs + i, TCG_TYPE_V256);
 }
-}
-if (TCG_TARGET_HAS_v128) {
+/* fallthru */
+case TCG_TYPE_V128:
 for (; i + 16 <= oprsz; i += 16) {
 tcg_gen_stl_vec(t_vec, cpu_env, dofs + i, TCG_TYPE_V128);
 }
-}
-if (TCG_TARGET_HAS_v64) {
+break;
+case TCG_TYPE_V64:
 for (; i < oprsz; i += 8) {
 tcg_gen_stl_vec(t_vec, cpu_env, dofs + i, TCG_TYPE_V64);
 }
+break;
+default:
+g_assert_not_reached();
 }
+
 tcg_temp_free_vec(t_vec);
 goto done;
 }
@@ -484,7 +522,7 @@ static void do_dup(unsigned vece, uint32_t dofs, uint32_t 
oprsz,
 }
 tcg_temp_free_i64(t_64);
 goto done;
-} 
+}
 }
 
 /* Otherwise implement out of line.  */
@@ -866,49 +904,55 @@ static void expand_4_vec(unsigned 

Re: [Qemu-devel] [PATCH] sparc: fix leon3 casa instruction when MMU is disabled

2018-03-02 Thread Richard Henderson
On 03/02/2018 01:59 AM, KONRAD Frederic wrote:
> From: KONRAD Frederic 
> 
> Since the commit af7a06bac7d3abb2da48ef3277d2a415772d2ae8:
> `casa [..](10), .., ..` (and probably others alternate space instructions)
> triggers a data access exception when the MMU is disabled.
> 
> When we enter get_asi(...) dc->mem_idx is set to MMU_PHYS_IDX when the MMU
> is disabled. Just keep mem_idx unchanged in this case so we passthrough the
> MMU when it is disabled.
> 
> Signed-off-by: KONRAD Frederic 
> ---
> 
> Notes:
> Changes RFC -> V1:
>  * emit the instruction with MMU_PHYS_IDX instead of checking that the MMU
>is enabled in get_physical_address(..)
> 
>  target/sparc/translate.c | 5 +
>  1 file changed, 5 insertions(+)

Reviewed-by: Richard Henderson 

r~



Re: [Qemu-devel] [PATCH 1/1] mm: gup: teach get_user_pages_unlocked to handle FOLL_NOWAIT

2018-03-02 Thread Andrew Morton
On Fri,  2 Mar 2018 18:43:43 +0100 Andrea Arcangeli  wrote:

> KVM is hanging during postcopy live migration with userfaultfd because
> get_user_pages_unlocked is not capable to handle FOLL_NOWAIT.
> 
> Earlier FOLL_NOWAIT was only ever passed to get_user_pages.
> 
> Specifically faultin_page (the callee of get_user_pages_unlocked
> caller) doesn't know that if FAULT_FLAG_RETRY_NOWAIT was set in the
> page fault flags, when VM_FAULT_RETRY is returned, the mmap_sem wasn't
> actually released (even if nonblocking is not NULL). So it sets
> *nonblocking to zero and the caller won't release the mmap_sem
> thinking it was already released, but it wasn't because of
> FOLL_NOWAIT.
> 
> Reported-by: Dr. David Alan Gilbert 
> Tested-by: Dr. David Alan Gilbert 
> Signed-off-by: Andrea Arcangeli 

I added

Fixes: ce53053ce378c ("kvm: switch get_user_page_nowait() to 
get_user_pages_unlocked()")
Cc: 



Re: [Qemu-devel] [PATCH 4/4] virtio-net: add linkspeed and duplex settings to virtio-net

2018-03-02 Thread Michael S. Tsirkin
On Fri, Mar 02, 2018 at 03:14:01PM +0800, Jason Wang wrote:
> 
> 
> On 2018年03月02日 11:46, Jason Baron wrote:
> > Although linkspeed and duplex can be set in a linux guest via 'ethtool -s',
> > this requires custom ethtool commands for virtio-net by default.
> > 
> > Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
> > the hypervisor to export a linkspeed and duplex setting. The user can
> > subsequently overwrite it later if desired via: 'ethtool -s'.
> > 
> > Linkspeed and duplex settings can be set as:
> > '-device virtio-net,speed=1,duplex=full'
> 
> I was thinking whether or not it's better to decide the duplex by the type
> of backends.
> 
> E.g userspace and vhost-kernel implement a in fact half duplex. But dpdk
> implement a full duplex.
> 
> Thanks

OTOH it's a priority for some people to be able to support migration
between different backend types. Breaking that won't be nice.

> > 
> > where speed is [0...INT_MAX], and duplex is ["half"|"full"].
> > 
> > Signed-off-by: Jason Baron
> > Cc: "Michael S. Tsirkin"
> > Cc: Jason Wang
> > Cc:virtio-...@lists.oasis-open.org
> > ---



[Qemu-devel] [PULL 05/37] gluster: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the gluster driver accordingly.

In want_zero mode, we continue to report fine-grained hole
information (the caller wants as much mapping detail as possible);
but when not in that mode, the caller prefers larger *pnum and
merely cares about what offsets are allocated at this layer, rather
than where the holes live.  Since holes still read as zeroes at
this layer (rather than deferring to a backing layer), we can take
the shortcut of skipping find_allocation(), and merely state that
all bytes are allocated.

We can also drop redundant bounds checks that are already
guaranteed by the block layer.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/gluster.c | 70 -
 1 file changed, 34 insertions(+), 36 deletions(-)

diff --git a/block/gluster.c b/block/gluster.c
index 3f17b7819d..1a07d221d1 100644
--- a/block/gluster.c
+++ b/block/gluster.c
@@ -1362,68 +1362,66 @@ exit:
 }
 
 /*
- * Returns the allocation status of the specified sectors.
+ * Returns the allocation status of the specified offset.
  *
- * If 'sector_num' is beyond the end of the disk image the return value is 0
- * and 'pnum' is set to 0.
+ * The block layer guarantees 'offset' and 'bytes' are within bounds.
  *
- * 'pnum' is set to the number of sectors (including and immediately following
- * the specified sector) that are known to be in the same
+ * 'pnum' is set to the number of bytes (including and immediately following
+ * the specified offset) that are known to be in the same
  * allocated/unallocated state.
  *
- * 'nb_sectors' is the max value 'pnum' should be set to.  If nb_sectors goes
- * beyond the end of the disk image it will be clamped.
+ * 'bytes' is the max value 'pnum' should be set to.
  *
- * (Based on raw_co_get_block_status() from file-posix.c.)
+ * (Based on raw_co_block_status() from file-posix.c.)
  */
-static int64_t coroutine_fn qemu_gluster_co_get_block_status(
-BlockDriverState *bs, int64_t sector_num, int nb_sectors, int *pnum,
-BlockDriverState **file)
+static int coroutine_fn qemu_gluster_co_block_status(BlockDriverState *bs,
+ bool want_zero,
+ int64_t offset,
+ int64_t bytes,
+ int64_t *pnum,
+ int64_t *map,
+ BlockDriverState **file)
 {
 BDRVGlusterState *s = bs->opaque;
-off_t start, data = 0, hole = 0;
-int64_t total_size;
+off_t data = 0, hole = 0;
 int ret = -EINVAL;
 
 if (!s->fd) {
 return ret;
 }
 
-start = sector_num * BDRV_SECTOR_SIZE;
-total_size = bdrv_getlength(bs);
-if (total_size < 0) {
-return total_size;
-} else if (start >= total_size) {
-*pnum = 0;
-return 0;
-} else if (start + nb_sectors * BDRV_SECTOR_SIZE > total_size) {
-nb_sectors = DIV_ROUND_UP(total_size - start, BDRV_SECTOR_SIZE);
+if (!want_zero) {
+*pnum = bytes;
+*map = offset;
+*file = bs;
+return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID;
 }
 
-ret = find_allocation(bs, start, , );
+ret = find_allocation(bs, offset, , );
 if (ret == -ENXIO) {
 /* Trailing hole */
-*pnum = nb_sectors;
+*pnum = bytes;
 ret = BDRV_BLOCK_ZERO;
 } else if (ret < 0) {
 /* No info available, so pretend there are no holes */
-*pnum = nb_sectors;
+*pnum = bytes;
 ret = BDRV_BLOCK_DATA;
-} else if (data == start) {
-/* On a data extent, compute sectors to the end of the extent,
+} else if (data == offset) {
+/* On a data extent, compute bytes to the end of the extent,
  * possibly including a partial sector at EOF. */
-*pnum = MIN(nb_sectors, DIV_ROUND_UP(hole - start, BDRV_SECTOR_SIZE));
+*pnum = MIN(bytes, hole - offset);
 ret = BDRV_BLOCK_DATA;
 } else {
-/* On a hole, compute sectors to the beginning of the next extent.  */
-assert(hole == start);
-*pnum = MIN(nb_sectors, (data - start) / BDRV_SECTOR_SIZE);
+/* On a hole, compute bytes to the beginning of the next extent.  */
+assert(hole == offset);
+*pnum = MIN(bytes, data - offset);
 ret = BDRV_BLOCK_ZERO;
 }
 
+*map = offset;
 *file = bs;
 
-return ret | BDRV_BLOCK_OFFSET_VALID | start;
+return ret | BDRV_BLOCK_OFFSET_VALID;
 }
 
 
@@ -1451,7 +1449,7 @@ static BlockDriver bdrv_gluster = {
 #ifdef 

[Qemu-devel] [PULL 02/37] nvme: Drop pointless .bdrv_co_get_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

Commit bdd6a90 has a bug: drivers should never directly set
BDRV_BLOCK_ALLOCATED, but only io.c should do that (as needed).
Instead, drivers should report BDRV_BLOCK_DATA if it knows that
data comes from this BDS.

But let's look at the bigger picture: semantically, the nvme
driver is similar to the nbd, null, and raw drivers (no backing
file, all data comes from this BDS).  But while two of those
other drivers have to supply the callback (null because it can
special-case BDRV_BLOCK_ZERO, raw because it can special-case
a different offset), in this case the block layer defaults are
good enough without the callback at all (similar to nbd).

So, fix the bug by deletion ;)

Signed-off-by: Eric Blake 
Signed-off-by: Kevin Wolf 
---
 block/nvme.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/block/nvme.c b/block/nvme.c
index 75078022f6..8bca57aae6 100644
--- a/block/nvme.c
+++ b/block/nvme.c
@@ -1072,18 +1072,6 @@ static int nvme_reopen_prepare(BDRVReopenState 
*reopen_state,
 return 0;
 }
 
-static int64_t coroutine_fn nvme_co_get_block_status(BlockDriverState *bs,
- int64_t sector_num,
- int nb_sectors, int *pnum,
- BlockDriverState **file)
-{
-*pnum = nb_sectors;
-*file = bs;
-
-return BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_OFFSET_VALID |
-   (sector_num << BDRV_SECTOR_BITS);
-}
-
 static void nvme_refresh_filename(BlockDriverState *bs, QDict *opts)
 {
 QINCREF(opts);
@@ -1183,8 +1171,6 @@ static BlockDriver bdrv_nvme = {
 .bdrv_co_flush_to_disk= nvme_co_flush,
 .bdrv_reopen_prepare  = nvme_reopen_prepare,
 
-.bdrv_co_get_block_status = nvme_co_get_block_status,
-
 .bdrv_refresh_filename= nvme_refresh_filename,
 .bdrv_refresh_limits  = nvme_refresh_limits,
 
-- 
2.13.6




[Qemu-devel] [PULL 04/37] file-posix: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the file protocol driver accordingly.

In want_zero mode, we continue to report fine-grained hole
information (the caller wants as much mapping detail as possible);
but when not in that mode, the caller prefers larger *pnum and
merely cares about what offsets are allocated at this layer, rather
than where the holes live.  Since holes still read as zeroes at
this layer (rather than deferring to a backing layer), we can take
the shortcut of skipping lseek(), and merely state that all bytes
are allocated.

We can also drop redundant bounds checks that are already
guaranteed by the block layer.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/file-posix.c | 64 +-
 1 file changed, 30 insertions(+), 34 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index ca49c1a98a..f1591c3849 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -2131,25 +2131,24 @@ static int find_allocation(BlockDriverState *bs, off_t 
start,
 }
 
 /*
- * Returns the allocation status of the specified sectors.
+ * Returns the allocation status of the specified offset.
  *
- * If 'sector_num' is beyond the end of the disk image the return value is 0
- * and 'pnum' is set to 0.
+ * The block layer guarantees 'offset' and 'bytes' are within bounds.
  *
- * 'pnum' is set to the number of sectors (including and immediately following
- * the specified sector) that are known to be in the same
+ * 'pnum' is set to the number of bytes (including and immediately following
+ * the specified offset) that are known to be in the same
  * allocated/unallocated state.
  *
- * 'nb_sectors' is the max value 'pnum' should be set to.  If nb_sectors goes
- * beyond the end of the disk image it will be clamped.
+ * 'bytes' is the max value 'pnum' should be set to.
  */
-static int64_t coroutine_fn raw_co_get_block_status(BlockDriverState *bs,
-int64_t sector_num,
-int nb_sectors, int *pnum,
-BlockDriverState **file)
-{
-off_t start, data = 0, hole = 0;
-int64_t total_size;
+static int coroutine_fn raw_co_block_status(BlockDriverState *bs,
+bool want_zero,
+int64_t offset,
+int64_t bytes, int64_t *pnum,
+int64_t *map,
+BlockDriverState **file)
+{
+off_t data = 0, hole = 0;
 int ret;
 
 ret = fd_open(bs);
@@ -2157,39 +2156,36 @@ static int64_t coroutine_fn 
raw_co_get_block_status(BlockDriverState *bs,
 return ret;
 }
 
-start = sector_num * BDRV_SECTOR_SIZE;
-total_size = bdrv_getlength(bs);
-if (total_size < 0) {
-return total_size;
-} else if (start >= total_size) {
-*pnum = 0;
-return 0;
-} else if (start + nb_sectors * BDRV_SECTOR_SIZE > total_size) {
-nb_sectors = DIV_ROUND_UP(total_size - start, BDRV_SECTOR_SIZE);
+if (!want_zero) {
+*pnum = bytes;
+*map = offset;
+*file = bs;
+return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID;
 }
 
-ret = find_allocation(bs, start, , );
+ret = find_allocation(bs, offset, , );
 if (ret == -ENXIO) {
 /* Trailing hole */
-*pnum = nb_sectors;
+*pnum = bytes;
 ret = BDRV_BLOCK_ZERO;
 } else if (ret < 0) {
 /* No info available, so pretend there are no holes */
-*pnum = nb_sectors;
+*pnum = bytes;
 ret = BDRV_BLOCK_DATA;
-} else if (data == start) {
-/* On a data extent, compute sectors to the end of the extent,
+} else if (data == offset) {
+/* On a data extent, compute bytes to the end of the extent,
  * possibly including a partial sector at EOF. */
-*pnum = MIN(nb_sectors, DIV_ROUND_UP(hole - start, BDRV_SECTOR_SIZE));
+*pnum = MIN(bytes, hole - offset);
 ret = BDRV_BLOCK_DATA;
 } else {
-/* On a hole, compute sectors to the beginning of the next extent.  */
-assert(hole == start);
-*pnum = MIN(nb_sectors, (data - start) / BDRV_SECTOR_SIZE);
+/* On a hole, compute bytes to the beginning of the next extent.  */
+assert(hole == offset);
+*pnum = MIN(bytes, data - offset);
 ret = BDRV_BLOCK_ZERO;
 }
+*map = offset;
 *file = bs;
-return ret | BDRV_BLOCK_OFFSET_VALID | start;
+return ret | BDRV_BLOCK_OFFSET_VALID;
 }
 
 static coroutine_fn BlockAIOCB 

[Qemu-devel] [PULL 22/37] block: fix write with zero flag set and iovector provided

2018-03-02 Thread Kevin Wolf
From: Anton Nefedov 

The normal bdrv_co_pwritev() use is either
  - BDRV_REQ_ZERO_WRITE clear and iovector provided
  - BDRV_REQ_ZERO_WRITE set and iovector == NULL

while
  - the flag clear and iovector == NULL is an assertion failure
in bdrv_co_do_zero_pwritev()
  - the flag set and iovector provided is in fact allowed
(the flag prevails and zeroes are written)

However the alignment logic does not support the latter case so the padding
areas get overwritten with zeroes.

Currently, general functions like bdrv_rw_co() do provide iovector
regardless of flags. So, keep it supported and use bdrv_co_do_zero_pwritev()
alignment for it which also makes the code a bit more obvious anyway.

Signed-off-by: Anton Nefedov 
Reviewed-by: Eric Blake 
Reviewed-by: Alberto Garcia 
Signed-off-by: Kevin Wolf 
---
 block/io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/io.c b/block/io.c
index 4c3dba0973..4d3d1f640a 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1701,7 +1701,7 @@ int coroutine_fn bdrv_co_pwritev(BdrvChild *child,
  */
 tracked_request_begin(, bs, offset, bytes, BDRV_TRACKED_WRITE);
 
-if (!qiov) {
+if (flags & BDRV_REQ_ZERO_WRITE) {
 ret = bdrv_co_do_zero_pwritev(child, offset, bytes, flags, );
 goto out;
 }
-- 
2.13.6




[Qemu-devel] [PULL 20/37] vvfat: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the vvfat driver accordingly.  Note that we
can rely on the block driver having already clamped limits to our
block size, and simplify accordingly.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/vvfat.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/block/vvfat.c b/block/vvfat.c
index 7e06ebacf6..4a17a49e12 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -3088,15 +3088,13 @@ vvfat_co_pwritev(BlockDriverState *bs, uint64_t offset, 
uint64_t bytes,
 return ret;
 }
 
-static int64_t coroutine_fn vvfat_co_get_block_status(BlockDriverState *bs,
-int64_t sector_num, int nb_sectors, int *n, BlockDriverState **file)
+static int coroutine_fn vvfat_co_block_status(BlockDriverState *bs,
+  bool want_zero, int64_t offset,
+  int64_t bytes, int64_t *n,
+  int64_t *map,
+  BlockDriverState **file)
 {
-*n = bs->total_sectors - sector_num;
-if (*n > nb_sectors) {
-*n = nb_sectors;
-} else if (*n < 0) {
-return 0;
-}
+*n = bytes;
 return BDRV_BLOCK_DATA;
 }
 
@@ -3257,7 +3255,7 @@ static BlockDriver bdrv_vvfat = {
 
 .bdrv_co_preadv = vvfat_co_preadv,
 .bdrv_co_pwritev= vvfat_co_pwritev,
-.bdrv_co_get_block_status = vvfat_co_get_block_status,
+.bdrv_co_block_status   = vvfat_co_block_status,
 };
 
 static void bdrv_vvfat_init(void)
-- 
2.13.6




Re: [Qemu-devel] [PATCH v2 0/2] Add a property to set the ARM CPU core count

2018-03-02 Thread Alistair Francis
On Fri, Mar 2, 2018 at 10:51 AM,   wrote:
> Hi,
>
> This series failed build test on ppcle host. Please find the details below.
>
...
>   CC  aarch64-softmmu/target/arm/helper-a64.o
>   LINKsparc64-softmmu/qemu-system-sparc64
>   CC  arm-softmmu/trace/control-target.o
>   CC  aarch64-softmmu/target/arm/gdbstub64.o
>   CC  aarch64-softmmu/target/arm/crypto_helper.o
>   CC  aarch64-softmmu/target/arm/arm-powerctl.o
>   LINKarmeb-linux-user/qemu-armeb
>   CC  arm-softmmu/gdbstub-xml.o
>   GEN trace/generated-helpers.c
>   CC  arm-softmmu/trace/generated-helpers.o
>   CC  aarch64-softmmu/trace/control-target.o
>   CC  aarch64-softmmu/gdbstub-xml.o
>   CC  aarch64-softmmu/trace/generated-helpers.o
>   LINKarm-linux-user/qemu-arm
> target/arm/cpu.o:(.toc+0x0): undefined reference to `smp_cpus'
> collect2: error: ld returned 1 exit status
> make[1]: *** [qemu-aarch64] Error 1
> make: *** [subdir-aarch64-linux-user] Error 2
> make: *** Waiting for unfinished jobs
> target/arm/cpu.o:(.toc+0x0): undefined reference to `smp_cpus'
> collect2: error: ld returned 1 exit status
> make[1]: *** [qemu-armeb] Error 1
> make: *** [subdir-armeb-linux-user] Error 2
>   LINKmipsel-linux-user/qemu-mipsel
> target/arm/cpu.o:(.toc+0x0): undefined reference to `smp_cpus'
> collect2: error: ld returned 1 exit status
> make[1]: *** [qemu-arm] Error 1
> make: *** [subdir-arm-linux-user] Error 2
>   LINKaarch64_be-linux-user/qemu-aarch64_be
> target/arm/cpu.o:(.toc+0x0): undefined reference to `smp_cpus'
> collect2: error: ld returned 1 exit status
> make[1]: *** [qemu-aarch64_be] Error 1
> make: *** [subdir-aarch64_be-linux-user] Error 2
>   LINKs390x-softmmu/qemu-system-s390x
>   LINKmipsn32el-linux-user/qemu-mipsn32el
>   LINKi386-softmmu/qemu-system-i386
>   LINKppc64-linux-user/qemu-ppc64
>   LINKx86_64-softmmu/qemu-system-x86_64
>   LINKppc64le-linux-user/qemu-ppc64le
>   LINKppc-linux-user/qemu-ppc
>   LINKmipsel-softmmu/qemu-system-mipsel
>   LINKppc64abi32-linux-user/qemu-ppc64abi32
>   LINKarm-softmmu/qemu-system-arm
>   LINKmips-softmmu/qemu-system-mips
>   LINKmips64el-softmmu/qemu-system-mips64el
>   LINKaarch64-softmmu/qemu-system-aarch64
>   LINKmips64-softmmu/qemu-system-mips64
>   LINKppcemb-softmmu/qemu-system-ppcemb
>   LINKppc-softmmu/qemu-system-ppc
>   LINKppc64-softmmu/qemu-system-ppc64
> === OUTPUT END ===

Argh! I rushed this through without waiting on the CI. I'll re-send V3.

Alistair

>
> Test command exited with code: 2
>
>
> ---
> Email generated automatically by Patchew [http://patchew.org/].
> Please send your feedback to patchew-de...@freelists.org



[Qemu-devel] [PULL 34/37] block/ssh: Pull ssh_grow_file() from ssh_create()

2018-03-02 Thread Kevin Wolf
From: Max Reitz 

If we ever want to offer even rudimentary truncation functionality for
ssh, we should put the respective code into a reusable function.

Signed-off-by: Max Reitz 
Message-id: 20180214204915.7980-2-mre...@redhat.com
Reviewed-by: Eric Blake 
Reviewed-by: Richard W.M. Jones 
Signed-off-by: Max Reitz 
---
 block/ssh.c | 30 ++
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/block/ssh.c b/block/ssh.c
index 36d5d888d5..d6a68cb880 100644
--- a/block/ssh.c
+++ b/block/ssh.c
@@ -803,6 +803,26 @@ static int ssh_file_open(BlockDriverState *bs, QDict 
*options, int bdrv_flags,
 return ret;
 }
 
+static int ssh_grow_file(BDRVSSHState *s, int64_t offset, Error **errp)
+{
+ssize_t ret;
+char c[1] = { '\0' };
+
+/* offset must be strictly greater than the current size so we do
+ * not overwrite anything */
+assert(offset > 0 && offset > s->attrs.filesize);
+
+libssh2_sftp_seek64(s->sftp_handle, offset - 1);
+ret = libssh2_sftp_write(s->sftp_handle, c, 1);
+if (ret < 0) {
+sftp_error_setg(errp, s, "Failed to grow file");
+return -EIO;
+}
+
+s->attrs.filesize = offset;
+return 0;
+}
+
 static QemuOptsList ssh_create_opts = {
 .name = "ssh-create-opts",
 .head = QTAILQ_HEAD_INITIALIZER(ssh_create_opts.head),
@@ -823,8 +843,6 @@ static int coroutine_fn ssh_co_create_opts(const char 
*filename, QemuOpts *opts,
 int64_t total_size = 0;
 QDict *uri_options = NULL;
 BDRVSSHState s;
-ssize_t r2;
-char c[1] = { '\0' };
 
 ssh_state_init();
 
@@ -850,14 +868,10 @@ static int coroutine_fn ssh_co_create_opts(const char 
*filename, QemuOpts *opts,
 }
 
 if (total_size > 0) {
-libssh2_sftp_seek64(s.sftp_handle, total_size-1);
-r2 = libssh2_sftp_write(s.sftp_handle, c, 1);
-if (r2 < 0) {
-sftp_error_setg(errp, , "truncate failed");
-ret = -EINVAL;
+ret = ssh_grow_file(, total_size, errp);
+if (ret < 0) {
 goto out;
 }
-s.attrs.filesize = total_size;
 }
 
 ret = 0;
-- 
2.13.6




[Qemu-devel] [PULL 1/3] tcg: Improve tcg_gen_muli_i32/i64

2018-03-02 Thread Richard Henderson
Convert multiplication by power of two to left shift.

Reviewed-by: Emilio G. Cota 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Richard Henderson 
---
 tcg/tcg-op.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/tcg/tcg-op.c b/tcg/tcg-op.c
index 3467787323..34b96d68f3 100644
--- a/tcg/tcg-op.c
+++ b/tcg/tcg-op.c
@@ -277,9 +277,15 @@ void tcg_gen_setcondi_i32(TCGCond cond, TCGv_i32 ret,
 
 void tcg_gen_muli_i32(TCGv_i32 ret, TCGv_i32 arg1, int32_t arg2)
 {
-TCGv_i32 t0 = tcg_const_i32(arg2);
-tcg_gen_mul_i32(ret, arg1, t0);
-tcg_temp_free_i32(t0);
+if (arg2 == 0) {
+tcg_gen_movi_i32(ret, 0);
+} else if (is_power_of_2(arg2)) {
+tcg_gen_shli_i32(ret, arg1, ctz32(arg2));
+} else {
+TCGv_i32 t0 = tcg_const_i32(arg2);
+tcg_gen_mul_i32(ret, arg1, t0);
+tcg_temp_free_i32(t0);
+}
 }
 
 void tcg_gen_div_i32(TCGv_i32 ret, TCGv_i32 arg1, TCGv_i32 arg2)
@@ -1430,9 +1436,15 @@ void tcg_gen_setcondi_i64(TCGCond cond, TCGv_i64 ret,
 
 void tcg_gen_muli_i64(TCGv_i64 ret, TCGv_i64 arg1, int64_t arg2)
 {
-TCGv_i64 t0 = tcg_const_i64(arg2);
-tcg_gen_mul_i64(ret, arg1, t0);
-tcg_temp_free_i64(t0);
+if (arg2 == 0) {
+tcg_gen_movi_i64(ret, 0);
+} else if (is_power_of_2(arg2)) {
+tcg_gen_shli_i64(ret, arg1, ctz64(arg2));
+} else {
+TCGv_i64 t0 = tcg_const_i64(arg2);
+tcg_gen_mul_i64(ret, arg1, t0);
+tcg_temp_free_i64(t0);
+}
 }
 
 void tcg_gen_div_i64(TCGv_i64 ret, TCGv_i64 arg1, TCGv_i64 arg2)
-- 
2.14.3




[Qemu-devel] [PULL 37/37] qcow2: Replace align_offset() with ROUND_UP()

2018-03-02 Thread Kevin Wolf
From: Alberto Garcia 

The align_offset() function is equivalent to the ROUND_UP() macro so
there's no need to use the former. The ROUND_UP() name is also a bit
more explicit.

This patch uses ROUND_UP() instead of the slower QEMU_ALIGN_UP()
because align_offset() already requires that the second parameter is a
power of two.

Signed-off-by: Alberto Garcia 
Reviewed-by: Eric Blake 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20180215131008.5153-1-be...@igalia.com
Signed-off-by: Max Reitz 
---
 block/qcow2.h  |  6 --
 block/qcow2-bitmap.c   |  4 ++--
 block/qcow2-cluster.c  |  4 ++--
 block/qcow2-refcount.c |  4 ++--
 block/qcow2-snapshot.c | 10 +-
 block/qcow2.c  | 14 +++---
 6 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/block/qcow2.h b/block/qcow2.h
index 883802241f..1a84cc77b0 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -480,12 +480,6 @@ static inline int offset_to_l2_slice_index(BDRVQcow2State 
*s, int64_t offset)
 return (offset >> s->cluster_bits) & (s->l2_slice_size - 1);
 }
 
-static inline int64_t align_offset(int64_t offset, int n)
-{
-offset = (offset + n - 1) & ~(n - 1);
-return offset;
-}
-
 static inline int64_t qcow2_vm_state_offset(BDRVQcow2State *s)
 {
 return (int64_t)s->l1_vm_state_index << (s->cluster_bits + s->l2_bits);
diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index 4f6fd863ea..5127276f90 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -413,8 +413,8 @@ static inline void 
bitmap_dir_entry_to_be(Qcow2BitmapDirEntry *entry)
 
 static inline int calc_dir_entry_size(size_t name_size, size_t extra_data_size)
 {
-return align_offset(sizeof(Qcow2BitmapDirEntry) +
-name_size + extra_data_size, 8);
+int size = sizeof(Qcow2BitmapDirEntry) + name_size + extra_data_size;
+return ROUND_UP(size, 8);
 }
 
 static inline int dir_entry_size(Qcow2BitmapDirEntry *entry)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index e406b0f3b9..98908c4264 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -126,11 +126,11 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t 
min_size,
 
 new_l1_size2 = sizeof(uint64_t) * new_l1_size;
 new_l1_table = qemu_try_blockalign(bs->file->bs,
-   align_offset(new_l1_size2, 512));
+   ROUND_UP(new_l1_size2, 512));
 if (new_l1_table == NULL) {
 return -ENOMEM;
 }
-memset(new_l1_table, 0, align_offset(new_l1_size2, 512));
+memset(new_l1_table, 0, ROUND_UP(new_l1_size2, 512));
 
 if (s->l1_size) {
 memcpy(new_l1_table, s->l1_table, s->l1_size * sizeof(uint64_t));
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index d46b69d7f3..126cca3276 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -1204,7 +1204,7 @@ int qcow2_update_snapshot_refcount(BlockDriverState *bs,
  * l1_table_offset when it is the current s->l1_table_offset! Be careful
  * when changing this! */
 if (l1_table_offset != s->l1_table_offset) {
-l1_table = g_try_malloc0(align_offset(l1_size2, 512));
+l1_table = g_try_malloc0(ROUND_UP(l1_size2, 512));
 if (l1_size2 && l1_table == NULL) {
 ret = -ENOMEM;
 goto fail;
@@ -2553,7 +2553,7 @@ int qcow2_check_metadata_overlap(BlockDriverState *bs, 
int ign, int64_t offset,
 }
 
 /* align range to test to cluster boundaries */
-size = align_offset(offset_into_cluster(s, offset) + size, 
s->cluster_size);
+size = ROUND_UP(offset_into_cluster(s, offset) + size, s->cluster_size);
 offset = start_of_cluster(s, offset);
 
 if ((chk & QCOW2_OL_ACTIVE_L1) && s->l1_size) {
diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index 44243e0e95..cee25f582b 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -66,7 +66,7 @@ int qcow2_read_snapshots(BlockDriverState *bs)
 
 for(i = 0; i < s->nb_snapshots; i++) {
 /* Read statically sized part of the snapshot header */
-offset = align_offset(offset, 8);
+offset = ROUND_UP(offset, 8);
 ret = bdrv_pread(bs->file, offset, , sizeof(h));
 if (ret < 0) {
 goto fail;
@@ -155,7 +155,7 @@ static int qcow2_write_snapshots(BlockDriverState *bs)
 offset = 0;
 for(i = 0; i < s->nb_snapshots; i++) {
 sn = s->snapshots + i;
-offset = align_offset(offset, 8);
+offset = ROUND_UP(offset, 8);
 offset += sizeof(h);
 offset += sizeof(extra);
 offset += strlen(sn->id_str);
@@ -215,7 +215,7 @@ static int qcow2_write_snapshots(BlockDriverState *bs)
 assert(id_str_size <= UINT16_MAX && name_size <= UINT16_MAX);
 h.id_str_size = cpu_to_be16(id_str_size);
 h.name_size = cpu_to_be16(name_size);
-offset = 

[Qemu-devel] [PULL 35/37] block/ssh: Make ssh_grow_file() blocking

2018-03-02 Thread Kevin Wolf
From: Max Reitz 

At runtime (that is, during a future ssh_truncate()), the SSH session is
non-blocking.  However, ssh_truncate() (or rather, bdrv_truncate() in
general) is not a coroutine, so this resize operation needs to block.

For ssh_create(), that is fine, too; the session is never set to
non-blocking anyway.

Signed-off-by: Max Reitz 
Message-id: 20180214204915.7980-3-mre...@redhat.com
Reviewed-by: Eric Blake 
Reviewed-by: Richard W.M. Jones 
Signed-off-by: Max Reitz 
---
 block/ssh.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/block/ssh.c b/block/ssh.c
index d6a68cb880..4bcf10334f 100644
--- a/block/ssh.c
+++ b/block/ssh.c
@@ -803,17 +803,24 @@ static int ssh_file_open(BlockDriverState *bs, QDict 
*options, int bdrv_flags,
 return ret;
 }
 
+/* Note: This is a blocking operation */
 static int ssh_grow_file(BDRVSSHState *s, int64_t offset, Error **errp)
 {
 ssize_t ret;
 char c[1] = { '\0' };
+int was_blocking = libssh2_session_get_blocking(s->session);
 
 /* offset must be strictly greater than the current size so we do
  * not overwrite anything */
 assert(offset > 0 && offset > s->attrs.filesize);
 
+libssh2_session_set_blocking(s->session, 1);
+
 libssh2_sftp_seek64(s->sftp_handle, offset - 1);
 ret = libssh2_sftp_write(s->sftp_handle, c, 1);
+
+libssh2_session_set_blocking(s->session, was_blocking);
+
 if (ret < 0) {
 sftp_error_setg(errp, s, "Failed to grow file");
 return -EIO;
-- 
2.13.6




[Qemu-devel] [PATCH v3 2/2] hw/arm: Set the core count for Xilinx's ZynqMP

2018-03-02 Thread Alistair Francis
Set the ARM CPU core count property for the A53's attached to the Xilnx
ZynqMP machine.

Signed-off-by: Alistair Francis 
Reviewed-by: Peter Maydell 
---

 hw/arm/xlnx-zynqmp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index 69227fd4c9..465796e97c 100644
--- a/hw/arm/xlnx-zynqmp.c
+++ b/hw/arm/xlnx-zynqmp.c
@@ -282,6 +282,8 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
**errp)
  s->virt, "has_el2", NULL);
 object_property_set_int(OBJECT(>apu_cpu[i]), GIC_BASE_ADDR,
 "reset-cbar", _abort);
+object_property_set_int(OBJECT(>apu_cpu[i]), num_apus,
+"core-count", _abort);
 object_property_set_bool(OBJECT(>apu_cpu[i]), true, "realized",
  );
 if (err) {
-- 
2.14.1




Re: [Qemu-devel] [PATCH QEMU v1 0/4] multiboot: bss_end_addr can be zero / cleanup

2018-03-02 Thread Jack Schwartz

Hi Kevin.

On 2018-01-15 07:54, Kevin Wolf wrote:

Am 21.12.2017 um 18:25 hat Jack Schwartz geschrieben:

Properly account for the possibility of multiboot kernels with a zero
bss_end_addr.  The Multiboot Specification, section 3.1.3 allows for
kernels without a bss section, by allowing a zeroed bss_end_addr multiboot
header field.

Do some cleanup to multiboot.c as well:
- Remove some unused variables.
- Use more intuitive header names when displaying fields in messages.
- Change fprintf(stderr...) to error_report

There are some conflicts with Anatol's (CCed) multiboot series:
https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg03003.html

None if these should be hard to resolve, but it would be good if you
could agree with each other whose patch series should come first, and
then the other one should be rebased on top of that.


Testing:
   1) Ran the "make check" test suite.
   2) Booted multiboot kernel with bss_end_addr=0.  (I rolled my own
  grub multiboot.elf test "kernel" by modifying source.)  Verified
  with gdb that new code that reads addresses/offsets from multiboot
  header was accessed.
   3) Booted multiboot kernel with non-zero bss_end_addr.
   4) Uncommented DEBUG_MULTIBOOT in multiboot.c and verified messages worked.
   5) Code has soaked in an internal repo for two months.

Can you integrate your test kernel from 2) in tests/multiboot/ so we can
keep this as a regression test?
If need be, would you be willing to accept updated versions of these 
patches (with another review, of course) without the test file?  I will 
deliver the test file later once I get company approvals.  I don't want 
the test file to continue holding everything up in the meantime.


Patchwork links, for reference:

1/4 multiboot: bss_end_addr can be zero
http://patchwork.ozlabs.org/patch/852049/

2/4 multiboot: Remove unused variables from multiboot.c
http://patchwork.ozlabs.org/patch/852045/

3/4 multiboot: Use header names when displaying fields
http://patchwork.ozlabs.org/patch/852046/

4/4 multiboot: fprintf(stderr...) -> error_report()
http://patchwork.ozlabs.org/patch/852051/


    Thanks,
    Jack



Jack Schwartz (4):
   multiboot: bss_end_addr can be zero
   multiboot: Remove unused variables from multiboot.c
   multiboot: Use header names when displaying fields
   multiboot: fprintf(stderr...) -> error_report()

Apart from the conflicts, the patches look good to me.

Kevin






Re: [Qemu-devel] [PATCH v2 0/2] ipmi: Fix vmstate transfer

2018-03-02 Thread Corey Minyard

On 03/02/2018 02:02 PM, Dr. David Alan Gilbert wrote:

* miny...@acm.org (miny...@acm.org) wrote:

I apologize for the resend, I left the list off the previous post.

This is unchanged since the previous post, two weeks ago.  I received
no comments, so I guess it's ok.  It's fairly broken now, so I would
like this fixed.

Sorry, I'll look at it on Monday; I was out last week and hadn't got
around to this set.


Thanks a bunch.  I have some doubt about how I handled the backwards
compatibility in the KCS code.  It works, but I'm not sure it's right.

-corey


Dave


Changes from v1:
   * Validate the data values in pre_load functions.
   * For KCS, instead of an old function, create a separate vmstate
 structure for the new version.  The name on the old vmstate
 structure wasn't specific enough, so a new name was needed,
 The old structure is set up to never be sent, but it can be
 received.

The following changes since commit 427cbc7e4136a061628cb4315cc8182ea36d772f:

   Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
(2018-03-01 18:46:41 +)

are available in the git repository at:

   https://github.com/cminyard/qemu.git tags/ipmi-vmstate-fixes

for you to fetch changes up to 90797371d9a3138657e7b1f7ab4425eb67d6fd0a:

   ipmi: Use proper struct reference for BT vmstate (2018-03-02 07:48:39 -0600)


Fix the IPMI vmstate code to work correctly in all cases.  Heavily
tested under load.


Corey Minyard (2):
   ipmi: Use proper struct reference for KCS vmstate
   ipmi: Use proper struct reference for BT vmstate

  hw/ipmi/isa_ipmi_bt.c  | 61 ++-
  hw/ipmi/isa_ipmi_kcs.c | 77 --
  2 files changed, 123 insertions(+), 15 deletions(-)


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






[Qemu-devel] [PULL 06/37] iscsi: Switch cluster_sectors to byte-based

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based.  Convert all uses of
the cluster size in sectors, along with adding assertions that we
are not dividing by zero.

Improve some comment grammar while in the area.

Signed-off-by: Eric Blake 
Acked-by: Paolo Bonzini 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/iscsi.c | 56 +++-
 1 file changed, 35 insertions(+), 21 deletions(-)

diff --git a/block/iscsi.c b/block/iscsi.c
index 421983dd6f..3414c21c7f 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -86,7 +86,7 @@ typedef struct IscsiLun {
 unsigned long *allocmap;
 unsigned long *allocmap_valid;
 long allocmap_size;
-int cluster_sectors;
+int cluster_size;
 bool use_16_for_rw;
 bool write_protected;
 bool lbpme;
@@ -430,9 +430,10 @@ static int iscsi_allocmap_init(IscsiLun *iscsilun, int 
open_flags)
 {
 iscsi_allocmap_free(iscsilun);
 
+assert(iscsilun->cluster_size);
 iscsilun->allocmap_size =
-DIV_ROUND_UP(sector_lun2qemu(iscsilun->num_blocks, iscsilun),
- iscsilun->cluster_sectors);
+DIV_ROUND_UP(iscsilun->num_blocks * iscsilun->block_size,
+ iscsilun->cluster_size);
 
 iscsilun->allocmap = bitmap_try_new(iscsilun->allocmap_size);
 if (!iscsilun->allocmap) {
@@ -440,7 +441,7 @@ static int iscsi_allocmap_init(IscsiLun *iscsilun, int 
open_flags)
 }
 
 if (open_flags & BDRV_O_NOCACHE) {
-/* in case that cache.direct = on all allocmap entries are
+/* when cache.direct = on all allocmap entries are
  * treated as invalid to force a relookup of the block
  * status on every read request */
 return 0;
@@ -461,17 +462,19 @@ iscsi_allocmap_update(IscsiLun *iscsilun, int64_t 
sector_num,
   int nb_sectors, bool allocated, bool valid)
 {
 int64_t cl_num_expanded, nb_cls_expanded, cl_num_shrunk, nb_cls_shrunk;
+int cluster_sectors = iscsilun->cluster_size >> BDRV_SECTOR_BITS;
 
 if (iscsilun->allocmap == NULL) {
 return;
 }
 /* expand to entirely contain all affected clusters */
-cl_num_expanded = sector_num / iscsilun->cluster_sectors;
+assert(cluster_sectors);
+cl_num_expanded = sector_num / cluster_sectors;
 nb_cls_expanded = DIV_ROUND_UP(sector_num + nb_sectors,
-   iscsilun->cluster_sectors) - 
cl_num_expanded;
+   cluster_sectors) - cl_num_expanded;
 /* shrink to touch only completely contained clusters */
-cl_num_shrunk = DIV_ROUND_UP(sector_num, iscsilun->cluster_sectors);
-nb_cls_shrunk = (sector_num + nb_sectors) / iscsilun->cluster_sectors
+cl_num_shrunk = DIV_ROUND_UP(sector_num, cluster_sectors);
+nb_cls_shrunk = (sector_num + nb_sectors) / cluster_sectors
   - cl_num_shrunk;
 if (allocated) {
 bitmap_set(iscsilun->allocmap, cl_num_expanded, nb_cls_expanded);
@@ -535,9 +538,12 @@ iscsi_allocmap_is_allocated(IscsiLun *iscsilun, int64_t 
sector_num,
 if (iscsilun->allocmap == NULL) {
 return true;
 }
-size = DIV_ROUND_UP(sector_num + nb_sectors, iscsilun->cluster_sectors);
+assert(iscsilun->cluster_size);
+size = DIV_ROUND_UP(sector_num + nb_sectors,
+iscsilun->cluster_size >> BDRV_SECTOR_BITS);
 return !(find_next_bit(iscsilun->allocmap, size,
-   sector_num / iscsilun->cluster_sectors) == size);
+   sector_num * BDRV_SECTOR_SIZE /
+   iscsilun->cluster_size) == size);
 }
 
 static inline bool iscsi_allocmap_is_valid(IscsiLun *iscsilun,
@@ -547,9 +553,12 @@ static inline bool iscsi_allocmap_is_valid(IscsiLun 
*iscsilun,
 if (iscsilun->allocmap_valid == NULL) {
 return false;
 }
-size = DIV_ROUND_UP(sector_num + nb_sectors, iscsilun->cluster_sectors);
+assert(iscsilun->cluster_size);
+size = DIV_ROUND_UP(sector_num + nb_sectors,
+iscsilun->cluster_size >> BDRV_SECTOR_BITS);
 return (find_next_zero_bit(iscsilun->allocmap_valid, size,
-   sector_num / iscsilun->cluster_sectors) == 
size);
+   sector_num * BDRV_SECTOR_SIZE /
+   iscsilun->cluster_size) == size);
 }
 
 static int coroutine_fn
@@ -793,16 +802,21 @@ static int coroutine_fn iscsi_co_readv(BlockDriverState 
*bs,
 BlockDriverState *file;
 /* check the block status from the beginning of the cluster
  * containing the start sector */
-int64_t ret = iscsi_co_get_block_status(bs,
-  sector_num - sector_num % iscsilun->cluster_sectors,
-  

[Qemu-devel] [PULL 03/37] block: Switch passthrough drivers to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the generic helpers, and all passthrough clients
(blkdebug, commit, mirror, throttle) accordingly.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 include/block/block_int.h | 28 
 block/blkdebug.c  | 20 +++-
 block/commit.c|  2 +-
 block/io.c| 36 
 block/mirror.c|  2 +-
 block/throttle.c  |  2 +-
 6 files changed, 50 insertions(+), 40 deletions(-)

diff --git a/include/block/block_int.h b/include/block/block_int.h
index c93722b43a..bf2598856c 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -1041,23 +1041,27 @@ void bdrv_format_default_perms(BlockDriverState *bs, 
BdrvChild *c,
uint64_t *nperm, uint64_t *nshared);
 
 /*
- * Default implementation for drivers to pass bdrv_co_get_block_status() to
+ * Default implementation for drivers to pass bdrv_co_block_status() to
  * their file.
  */
-int64_t coroutine_fn bdrv_co_get_block_status_from_file(BlockDriverState *bs,
-int64_t sector_num,
-int nb_sectors,
-int *pnum,
-BlockDriverState 
**file);
+int coroutine_fn bdrv_co_block_status_from_file(BlockDriverState *bs,
+bool want_zero,
+int64_t offset,
+int64_t bytes,
+int64_t *pnum,
+int64_t *map,
+BlockDriverState **file);
 /*
- * Default implementation for drivers to pass bdrv_co_get_block_status() to
+ * Default implementation for drivers to pass bdrv_co_block_status() to
  * their backing file.
  */
-int64_t coroutine_fn bdrv_co_get_block_status_from_backing(BlockDriverState 
*bs,
-   int64_t sector_num,
-   int nb_sectors,
-   int *pnum,
-   BlockDriverState 
**file);
+int coroutine_fn bdrv_co_block_status_from_backing(BlockDriverState *bs,
+   bool want_zero,
+   int64_t offset,
+   int64_t bytes,
+   int64_t *pnum,
+   int64_t *map,
+   BlockDriverState **file);
 const char *bdrv_get_parent_name(const BlockDriverState *bs);
 void blk_dev_change_media_cb(BlockBackend *blk, bool load, Error **errp);
 bool blk_dev_has_removable_media(BlockBackend *blk);
diff --git a/block/blkdebug.c b/block/blkdebug.c
index d83f23febd..589712475a 100644
--- a/block/blkdebug.c
+++ b/block/blkdebug.c
@@ -627,15 +627,17 @@ static int coroutine_fn 
blkdebug_co_pdiscard(BlockDriverState *bs,
 return bdrv_co_pdiscard(bs->file->bs, offset, bytes);
 }
 
-static int64_t coroutine_fn blkdebug_co_get_block_status(
-BlockDriverState *bs, int64_t sector_num, int nb_sectors, int *pnum,
-BlockDriverState **file)
+static int coroutine_fn blkdebug_co_block_status(BlockDriverState *bs,
+ bool want_zero,
+ int64_t offset,
+ int64_t bytes,
+ int64_t *pnum,
+ int64_t *map,
+ BlockDriverState **file)
 {
-assert(QEMU_IS_ALIGNED(sector_num | nb_sectors,
-   DIV_ROUND_UP(bs->bl.request_alignment,
-BDRV_SECTOR_SIZE)));
-return bdrv_co_get_block_status_from_file(bs, sector_num, nb_sectors,
-  pnum, file);
+assert(QEMU_IS_ALIGNED(offset | bytes, bs->bl.request_alignment));
+return bdrv_co_block_status_from_file(bs, want_zero, offset, bytes,
+  pnum, map, file);
 }
 
 static void blkdebug_close(BlockDriverState *bs)
@@ -907,7 +909,7 @@ static BlockDriver bdrv_blkdebug = {
 .bdrv_co_flush_to_disk  = blkdebug_co_flush,
 

[Qemu-devel] [PULL 17/37] vdi: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the vdi driver accordingly.  Note that the
TODO is already covered (the block layer guarantees bounds of its
requests), and that we can remove the now-unused s->block_sectors.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/vdi.c | 33 +
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/block/vdi.c b/block/vdi.c
index 32b1763cde..0780c82d82 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -172,8 +172,6 @@ typedef struct {
 uint32_t *bmap;
 /* Size of block (bytes). */
 uint32_t block_size;
-/* Size of block (sectors). */
-uint32_t block_sectors;
 /* First sector of block map. */
 uint32_t bmap_sector;
 /* VDI header (converted to host endianness). */
@@ -463,7 +461,6 @@ static int vdi_open(BlockDriverState *bs, QDict *options, 
int flags,
 bs->total_sectors = header.disk_size / SECTOR_SIZE;
 
 s->block_size = header.block_size;
-s->block_sectors = header.block_size / SECTOR_SIZE;
 s->bmap_sector = header.offset_bmap / SECTOR_SIZE;
 s->header = header;
 
@@ -509,33 +506,29 @@ static int vdi_reopen_prepare(BDRVReopenState *state,
 return 0;
 }
 
-static int64_t coroutine_fn vdi_co_get_block_status(BlockDriverState *bs,
-int64_t sector_num, int nb_sectors, int *pnum, BlockDriverState **file)
+static int coroutine_fn vdi_co_block_status(BlockDriverState *bs,
+bool want_zero,
+int64_t offset, int64_t bytes,
+int64_t *pnum, int64_t *map,
+BlockDriverState **file)
 {
-/* TODO: Check for too large sector_num (in bdrv_is_allocated or here). */
 BDRVVdiState *s = (BDRVVdiState *)bs->opaque;
-size_t bmap_index = sector_num / s->block_sectors;
-size_t sector_in_block = sector_num % s->block_sectors;
-int n_sectors = s->block_sectors - sector_in_block;
+size_t bmap_index = offset / s->block_size;
+size_t index_in_block = offset % s->block_size;
 uint32_t bmap_entry = le32_to_cpu(s->bmap[bmap_index]);
-uint64_t offset;
 int result;
 
-logout("%p, %" PRId64 ", %d, %p\n", bs, sector_num, nb_sectors, pnum);
-if (n_sectors > nb_sectors) {
-n_sectors = nb_sectors;
-}
-*pnum = n_sectors;
+logout("%p, %" PRId64 ", %" PRId64 ", %p\n", bs, offset, bytes, pnum);
+*pnum = MIN(s->block_size - index_in_block, bytes);
 result = VDI_IS_ALLOCATED(bmap_entry);
 if (!result) {
 return 0;
 }
 
-offset = s->header.offset_data +
-  (uint64_t)bmap_entry * s->block_size +
-  sector_in_block * SECTOR_SIZE;
+*map = s->header.offset_data + (uint64_t)bmap_entry * s->block_size +
+index_in_block;
 *file = bs->file->bs;
-return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID | offset;
+return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID;
 }
 
 static int coroutine_fn
@@ -903,7 +896,7 @@ static BlockDriver bdrv_vdi = {
 .bdrv_child_perm  = bdrv_format_default_perms,
 .bdrv_create = vdi_create,
 .bdrv_has_zero_init = bdrv_has_zero_init_1,
-.bdrv_co_get_block_status = vdi_co_get_block_status,
+.bdrv_co_block_status = vdi_co_block_status,
 .bdrv_make_empty = vdi_make_empty,
 
 .bdrv_co_preadv = vdi_co_preadv,
-- 
2.13.6




[Qemu-devel] [PULL 0/3] tcg queued patches

2018-03-02 Thread Richard Henderson
Only three outstanding patches for now.


r~


Richard Henderson (3):
  tcg: Improve tcg_gen_muli_i32/i64
  tcg/i386: Support INDEX_op_dup2_vec for -m32
  tcg: Add choose_vector_size

 tcg/i386/tcg-target.inc.c |   9 +
 tcg/tcg-op-gvec.c | 438 +++---
 tcg/tcg-op.c  |  24 ++-
 3 files changed, 286 insertions(+), 185 deletions(-)

-- 
2.14.3




[Qemu-devel] [PULL 28/37] block: add BlockBackend->in_flight counter

2018-03-02 Thread Kevin Wolf
From: Stefan Hajnoczi 

BlockBackend currently relies on BlockDriverState->in_flight to track
requests for blk_drain().  There is a corner case where
BlockDriverState->in_flight cannot be used though: blk->root can be NULL
when there is no medium.  This results in a segfault when the NULL
pointer is dereferenced.

Introduce a BlockBackend->in_flight counter for aio requests so it works
even when blk->root == NULL.

Based on a patch by Kevin Wolf .

Signed-off-by: Kevin Wolf 
Signed-off-by: Stefan Hajnoczi 
Signed-off-by: Kevin Wolf 
---
 block.c   |  2 +-
 block/block-backend.c | 60 +--
 2 files changed, 54 insertions(+), 8 deletions(-)

diff --git a/block.c b/block.c
index 9e4da81213..a83037c2a5 100644
--- a/block.c
+++ b/block.c
@@ -4713,7 +4713,7 @@ out:
 
 AioContext *bdrv_get_aio_context(BlockDriverState *bs)
 {
-return bs->aio_context;
+return bs ? bs->aio_context : qemu_get_aio_context();
 }
 
 AioWait *bdrv_get_aio_wait(BlockDriverState *bs)
diff --git a/block/block-backend.c b/block/block-backend.c
index 0266ac990b..a775a3dd2f 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -73,6 +73,14 @@ struct BlockBackend {
 int quiesce_counter;
 VMChangeStateEntry *vmsh;
 bool force_allow_inactivate;
+
+/* Number of in-flight aio requests.  BlockDriverState also counts
+ * in-flight requests but aio requests can exist even when blk->root is
+ * NULL, so we cannot rely on its counter for that case.
+ * Accessed with atomic ops.
+ */
+unsigned int in_flight;
+AioWait wait;
 };
 
 typedef struct BlockBackendAIOCB {
@@ -1225,11 +1233,22 @@ int blk_make_zero(BlockBackend *blk, BdrvRequestFlags 
flags)
 return bdrv_make_zero(blk->root, flags);
 }
 
+static void blk_inc_in_flight(BlockBackend *blk)
+{
+atomic_inc(>in_flight);
+}
+
+static void blk_dec_in_flight(BlockBackend *blk)
+{
+atomic_dec(>in_flight);
+aio_wait_kick(>wait);
+}
+
 static void error_callback_bh(void *opaque)
 {
 struct BlockBackendAIOCB *acb = opaque;
 
-bdrv_dec_in_flight(acb->common.bs);
+blk_dec_in_flight(acb->blk);
 acb->common.cb(acb->common.opaque, acb->ret);
 qemu_aio_unref(acb);
 }
@@ -1240,7 +1259,7 @@ BlockAIOCB *blk_abort_aio_request(BlockBackend *blk,
 {
 struct BlockBackendAIOCB *acb;
 
-bdrv_inc_in_flight(blk_bs(blk));
+blk_inc_in_flight(blk);
 acb = blk_aio_get(_backend_aiocb_info, blk, cb, opaque);
 acb->blk = blk;
 acb->ret = ret;
@@ -1263,7 +1282,7 @@ static const AIOCBInfo blk_aio_em_aiocb_info = {
 static void blk_aio_complete(BlkAioEmAIOCB *acb)
 {
 if (acb->has_returned) {
-bdrv_dec_in_flight(acb->common.bs);
+blk_dec_in_flight(acb->rwco.blk);
 acb->common.cb(acb->common.opaque, acb->rwco.ret);
 qemu_aio_unref(acb);
 }
@@ -1284,7 +1303,7 @@ static BlockAIOCB *blk_aio_prwv(BlockBackend *blk, 
int64_t offset, int bytes,
 BlkAioEmAIOCB *acb;
 Coroutine *co;
 
-bdrv_inc_in_flight(blk_bs(blk));
+blk_inc_in_flight(blk);
 acb = blk_aio_get(_aio_em_aiocb_info, blk, cb, opaque);
 acb->rwco = (BlkRwCo) {
 .blk= blk,
@@ -1521,14 +1540,41 @@ int blk_flush(BlockBackend *blk)
 
 void blk_drain(BlockBackend *blk)
 {
-if (blk_bs(blk)) {
-bdrv_drain(blk_bs(blk));
+BlockDriverState *bs = blk_bs(blk);
+
+if (bs) {
+bdrv_drained_begin(bs);
+}
+
+/* We may have -ENOMEDIUM completions in flight */
+AIO_WAIT_WHILE(>wait,
+blk_get_aio_context(blk),
+atomic_mb_read(>in_flight) > 0);
+
+if (bs) {
+bdrv_drained_end(bs);
 }
 }
 
 void blk_drain_all(void)
 {
-bdrv_drain_all();
+BlockBackend *blk = NULL;
+
+bdrv_drain_all_begin();
+
+while ((blk = blk_all_next(blk)) != NULL) {
+AioContext *ctx = blk_get_aio_context(blk);
+
+aio_context_acquire(ctx);
+
+/* We may have -ENOMEDIUM completions in flight */
+AIO_WAIT_WHILE(>wait, ctx,
+atomic_mb_read(>in_flight) > 0);
+
+aio_context_release(ctx);
+}
+
+bdrv_drain_all_end();
 }
 
 void blk_set_on_error(BlockBackend *blk, BlockdevOnError on_read_error,
-- 
2.13.6




[Qemu-devel] [PATCH v3 0/2] Add a property to set the ARM CPU core count

2018-03-02 Thread Alistair Francis

Add an ARM CPU property which allows us to set the ARM CPU core count.
V3:
 - Fix Linux user mode compile failure

V2:
 - Fix commit message and title.
 - Move the core_count default setting logic to the arm_cpu_realize()
   function.


Alistair Francis (2):
  target/arm: Add a core count property
  hw/arm: Set the core count for Xilinx's ZynqMP

 target/arm/cpu.h | 5 +
 hw/arm/xlnx-zynqmp.c | 2 ++
 target/arm/cpu.c | 6 ++
 target/arm/cpu64.c   | 6 --
 4 files changed, 17 insertions(+), 2 deletions(-)

-- 
2.14.1




Re: [Qemu-devel] [PATCH v2 0/2] ipmi: Fix vmstate transfer

2018-03-02 Thread Dr. David Alan Gilbert
* miny...@acm.org (miny...@acm.org) wrote:
> I apologize for the resend, I left the list off the previous post.
> 
> This is unchanged since the previous post, two weeks ago.  I received
> no comments, so I guess it's ok.  It's fairly broken now, so I would
> like this fixed.

Sorry, I'll look at it on Monday; I was out last week and hadn't got
around to this set.

Dave

> Changes from v1:
>   * Validate the data values in pre_load functions.
>   * For KCS, instead of an old function, create a separate vmstate
> structure for the new version.  The name on the old vmstate
> structure wasn't specific enough, so a new name was needed,
> The old structure is set up to never be sent, but it can be
> received.
> 
> The following changes since commit 427cbc7e4136a061628cb4315cc8182ea36d772f:
> 
>   Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
> (2018-03-01 18:46:41 +)
> 
> are available in the git repository at:
> 
>   https://github.com/cminyard/qemu.git tags/ipmi-vmstate-fixes
> 
> for you to fetch changes up to 90797371d9a3138657e7b1f7ab4425eb67d6fd0a:
> 
>   ipmi: Use proper struct reference for BT vmstate (2018-03-02 07:48:39 -0600)
> 
> 
> Fix the IPMI vmstate code to work correctly in all cases.  Heavily
> tested under load.
> 
> 
> Corey Minyard (2):
>   ipmi: Use proper struct reference for KCS vmstate
>   ipmi: Use proper struct reference for BT vmstate
> 
>  hw/ipmi/isa_ipmi_bt.c  | 61 ++-
>  hw/ipmi/isa_ipmi_kcs.c | 77 
> --
>  2 files changed, 123 insertions(+), 15 deletions(-)
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] [PULL 12/51] build-sys: compile with -Og or -O1 when --enable-debug

2018-03-02 Thread Alex Bennée

Peter Maydell  writes:

> On 16 January 2018 at 14:16, Paolo Bonzini  wrote:
>> From: Marc-André Lureau 
>>
>> When --enable-debug is turned on, configure doesn't set -O level, and
>> uses default compiler -O0 level, which is slow.
>>
>> Instead, use -Og if supported by the compiler (optimize debugging
>> experience), or -O1 (keeps code somewhat debuggable and works around
>> compiler bugs).
>
> This gives me a noticeably worse debug experience (using -Og),
> because gdb shows a lot more "" variables and
> function arguments. (I've been mildly irritated by this for
> the last few weeks and only just figured out why this was
> happening.)

I was wondering why my:

   ./configure --enable-debug --enable-debug-tcg --extra-cflags="-O0 -g3" 
--target-list=aarch64-linux-user

builds where showing that.

> Can we go back to the previous behaviour, please ? I don't
> care if the build is slow if I'm debugging, but I really do
> care that I don't have my variables and arguments all
> optimised away by the compiler so I can't tell what's going on.

+1

There is a lot of other stuff enabled when debugging which slows stuff
down anyway.

--
Alex Bennée



[Qemu-devel] [PULL 11/37] qcow: Switch to .bdrv_co_block_status()

2018-03-02 Thread Kevin Wolf
From: Eric Blake 

We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the qcow driver accordingly.  There is no
intent to optimize based on the want_zero flag for this format.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 block/qcow.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/block/qcow.c b/block/qcow.c
index 8631155ac8..dead5029c6 100644
--- a/block/qcow.c
+++ b/block/qcow.c
@@ -524,23 +524,28 @@ static int get_cluster_offset(BlockDriverState *bs,
 return 1;
 }
 
-static int64_t coroutine_fn qcow_co_get_block_status(BlockDriverState *bs,
-int64_t sector_num, int nb_sectors, int *pnum, BlockDriverState **file)
+static int coroutine_fn qcow_co_block_status(BlockDriverState *bs,
+ bool want_zero,
+ int64_t offset, int64_t bytes,
+ int64_t *pnum, int64_t *map,
+ BlockDriverState **file)
 {
 BDRVQcowState *s = bs->opaque;
-int index_in_cluster, n, ret;
+int index_in_cluster, ret;
+int64_t n;
 uint64_t cluster_offset;
 
 qemu_co_mutex_lock(>lock);
-ret = get_cluster_offset(bs, sector_num << 9, 0, 0, 0, 0, _offset);
+ret = get_cluster_offset(bs, offset, 0, 0, 0, 0, _offset);
 qemu_co_mutex_unlock(>lock);
 if (ret < 0) {
 return ret;
 }
-index_in_cluster = sector_num & (s->cluster_sectors - 1);
-n = s->cluster_sectors - index_in_cluster;
-if (n > nb_sectors)
-n = nb_sectors;
+index_in_cluster = offset & (s->cluster_size - 1);
+n = s->cluster_size - index_in_cluster;
+if (n > bytes) {
+n = bytes;
+}
 *pnum = n;
 if (!cluster_offset) {
 return 0;
@@ -548,9 +553,9 @@ static int64_t coroutine_fn 
qcow_co_get_block_status(BlockDriverState *bs,
 if ((cluster_offset & QCOW_OFLAG_COMPRESSED) || s->crypto) {
 return BDRV_BLOCK_DATA;
 }
-cluster_offset |= (index_in_cluster << BDRV_SECTOR_BITS);
+*map = cluster_offset | index_in_cluster;
 *file = bs->file->bs;
-return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID | cluster_offset;
+return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID;
 }
 
 static int decompress_buffer(uint8_t *out_buf, int out_buf_size,
@@ -1128,7 +1133,7 @@ static BlockDriver bdrv_qcow = {
 
 .bdrv_co_readv  = qcow_co_readv,
 .bdrv_co_writev = qcow_co_writev,
-.bdrv_co_get_block_status   = qcow_co_get_block_status,
+.bdrv_co_block_status   = qcow_co_block_status,
 
 .bdrv_make_empty= qcow_make_empty,
 .bdrv_co_pwritev_compressed = qcow_co_pwritev_compressed,
-- 
2.13.6




  1   2   3   4   >