Re: [Qemu-devel] [RFC PATCH v1 4/6] spapr: Consolidate HPT freeing code into a routine

[David Gibson]

On Wed, May 17, 2017 at 09:19:20AM +0530, Bharata B Rao wrote:
> Consolidate the code that frees HPT into a separate routine
> spapr_free_hpt() as the same chunk of code is called from two places.
> 
> Signed-off-by: Bharata B Rao 

Applied to ppc-for-2.10.  This is a good clean up in its own right.
Plus it will be useful to me to get my HPT resizing patches integrated
with radix support.

> ---
>  hw/ppc/spapr.c | 13 +
>  hw/ppc/spapr_hcall.c   |  5 +
>  include/hw/ppc/spapr.h |  1 +
>  3 files changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 1b7cada..521eef1 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1222,16 +1222,21 @@ static int spapr_hpt_shift_for_ramsize(uint64_t 
> ramsize)
>  return shift;
>  }
>  
> +void spapr_free_hpt(sPAPRMachineState *spapr)
> +{
> +g_free(spapr->htab);
> +spapr->htab = NULL;
> +spapr->htab_shift = 0;
> +close_htab_fd(spapr);
> +}
> +
>  static void spapr_reallocate_hpt(sPAPRMachineState *spapr, int shift,
>   Error **errp)
>  {
>  long rc;
>  
>  /* Clean up any HPT info from a previous boot */
> -g_free(spapr->htab);
> -spapr->htab = NULL;
> -spapr->htab_shift = 0;
> -close_htab_fd(spapr);
> +spapr_free_hpt(spapr);
>  
>  rc = kvmppc_reset_htab(shift);
>  if (rc < 0) {
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 3600b0e..be79e3d 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -913,10 +913,7 @@ static void spapr_check_setup_free_hpt(sPAPRMachineState 
> *spapr,
>  /* We assume RADIX, so this catches all the "Do Nothing" cases */
>  } else if (!(patbe_old & PATBE1_GR)) {
>  /* HASH->RADIX : Free HPT */
> -g_free(spapr->htab);
> -spapr->htab = NULL;
> -spapr->htab_shift = 0;
> -close_htab_fd(spapr);
> +spapr_free_hpt(spapr);
>  } else if (!(patbe_new & PATBE1_GR)) {
>  /* RADIX->HASH || NOTHING->HASH : Allocate HPT */
>  spapr_setup_hpt_and_vrma(spapr);
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index a692e63..6f9cb85 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -610,6 +610,7 @@ int spapr_h_cas_compose_response(sPAPRMachineState *sm,
>   sPAPROptionVector *ov5_updates);
>  void close_htab_fd(sPAPRMachineState *spapr);
>  void spapr_setup_hpt_and_vrma(sPAPRMachineState *spapr);
> +void spapr_free_hpt(sPAPRMachineState *spapr);
>  sPAPRTCETable *spapr_tce_new_table(DeviceState *owner, uint32_t liobn);
>  void spapr_tce_table_enable(sPAPRTCETable *tcet,
>  uint32_t page_shift, uint64_t bus_offset,

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PULL 19/48] spapr: allocate the ICPState object from under sPAPRCPUCore

[David Gibson]

On Wed, May 17, 2017 at 07:50:42AM +0200, Cédric Le Goater wrote:
> On 05/16/2017 06:10 PM, Greg Kurz wrote:
> > On Tue, 16 May 2017 17:18:27 +0200
> > Cédric Le Goater  wrote:
> > 
> >> On 05/16/2017 02:55 PM, Laurent Vivier wrote:
> >>> On 16/05/2017 14:50, Cédric Le Goater wrote:  
>  On 05/16/2017 02:03 PM, Laurent Vivier wrote:  
> > On 26/04/2017 09:00, David Gibson wrote:  
> >> From: Cédric Le Goater 
> >>
> >> Today, all the ICPs are created before the CPUs, stored in an array
> >> under the sPAPR machine and linked to the CPU when the core threads
> >> are realized. This modeling brings some complexity when a lookup in
> >> the array is required and it can be simplified by allocating the ICPs
> >> when the CPUs are.
> >>
> >> This is the purpose of this proposal which introduces a new 'icp_type'
> >> field under the machine and creates the ICP objects of the right type
> >> (KVM or not) before the PowerPCCPU object are.
> >>
> >> This change allows more cleanups : the removal of the icps array under
> >> the sPAPR machine and the removal of the xics_get_cpu_index_by_dt_id()
> >> helper.
> >>
> >> Signed-off-by: Cédric Le Goater 
> >> Reviewed-by: David Gibson 
> >> Signed-off-by: David Gibson 
> >> ---
> >>  hw/intc/xics.c  | 11 ---
> >>  hw/ppc/spapr.c  | 47 
> >> ++-
> >>  hw/ppc/spapr_cpu_core.c | 18 ++
> >>  include/hw/ppc/spapr.h  |  2 +-
> >>  include/hw/ppc/xics.h   |  2 --
> >>  5 files changed, 29 insertions(+), 51 deletions(-)
> >>  
> >
> > This commit breaks CPU re-hotplugging with KVM
> >
> > the sequence "device_add, device_del, device_add" brings to the
> > following error message:
> >
> > Unable to connect CPUx to kernel XICS: Device or resource busy
> >
> > It comes from icp_kvm_cpu_setup():
> >
> > ...
> > ret = kvm_vcpu_enable_cap(cs, KVM_CAP_IRQ_XICS, 0, kernel_xics_fd,
> >   kvm_arch_vcpu_id(cs));
> > if (ret < 0) {
> > error_report("Unable to connect CPU%ld to kernel XICS: %s",
> >  kvm_arch_vcpu_id(cs), strerror(errno));
> > exit(1);
> > }
> > ..
> >
> > It should be protected by cap_irq_xics_enabled:
> >
> > ...
> > /*
> >  * If we are reusing a parked vCPU fd corresponding to the CPU
> >  * which was hot-removed earlier we don't have to renable
> >  * KVM_CAP_IRQ_XICS capability again.
> >  */
> > if (icp->cap_irq_xics_enabled) {
> > return;
> > }
> >
> > ...
> > ret = kvm_vcpu_enable_cap(...);
> > ...
> > icp->cap_irq_xics_enabled = true;
> > ...
> >
> > But since this commit, "icp" is a new object on each call:
> >
> > spapr_cpu_core_realize_child()
> > ...
> > obj = object_new(spapr->icp_type);
> > ...
> > xics_cpu_setup(XICS_FABRIC(spapr), cpu, ICP(obj));
> > ...
> > icpc->cpu_setup(icp, cpu); -> icp_kvm_cpu_setup()
> > ...
> > ...
> >
> > and "cap_irq_xics_enabled" is reinitialized.
> >
> > Any idea how to fix that?  
> 
>  it seems that a cleanup is not done in the kernel. We are missing
>  a way to call kvmppc_xics_free_icp() from QEMU. Today the only
>  way is to destroy the vcpu.   
> >>>
> >>> The commit introducing this hack, for reference:
> >>>
> >>> commit a45863bda90daa8ec39e5a312b9734fd4665b016
> >>> Author: Bharata B Rao 
> >>> Date:   Thu Jul 2 16:23:20 2015 +1000
> >>>
> >>> xics_kvm: Don't enable KVM_CAP_IRQ_XICS if already enabled
> >>> 
> >>> When supporting CPU hot removal by parking the vCPU fd and reusing
> >>> it during hotplug again, there can be cases where we try to reenable
> >>> KVM_CAP_IRQ_XICS CAP for the vCPU for which it was already enabled.
> >>> Introduce a boolean member in ICPState to track this and don't
> >>> reenable the CAP if it was already enabled earlier.
> >>> 
> >>> Re-enabling this CAP should ideally work, but currently it results in
> >>> kernel trying to create and associate ICP with this vCPU and that
> >>> fails since there is already an ICP associated with it. Hence this
> >>> patch is needed to work around this problem in the kernel.
> >>> 
> >>> This change allows CPU hot removal to work for sPAPR.
> >>> 
> >>> Signed-off-by: Bharata B Rao 
> >>> Reviewed-by: David Gibson 
> >>> Signed-off-by: David Gibson 
> >>> Signed-off-by: Alexander Graf   
> >>
> >> OK. 
> >>
> >> Greg is looking at re-adding the ICPState array because of a 
> >> migration issue with older machines. We might need to do so 
> >> unconditionally ...
> >>
> > 
> > That would be a pity to carry on wit

Re: [Qemu-devel] [RFC PATCH v1 1/6] migration: Fix unregister_savevm()

[David Gibson]

On Wed, May 17, 2017 at 09:19:17AM +0530, Bharata B Rao wrote:
> In unregister_savevm(), free se->compat only if it was allocated earlier.
> 
> Signed-off-by: Bharata B Rao 

I don't think this is necessary.  If se->compat was never allocated,
then it should be NULL (since se is allocated with g_new0()).
g_free() is explicitly safe to call on NULL, and we already rely on
that in qemu.

> ---
>  migration/savevm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/migration/savevm.c b/migration/savevm.c
> index 352a8f2..7a268ec 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -648,7 +648,9 @@ void unregister_savevm(DeviceState *dev, const char 
> *idstr, void *opaque)
>  QTAILQ_FOREACH_SAFE(se, &savevm_state.handlers, entry, new_se) {
>  if (strcmp(se->idstr, id) == 0 && se->opaque == opaque) {
>  QTAILQ_REMOVE(&savevm_state.handlers, se, entry);
> -g_free(se->compat);
> +if (dev) {
> +g_free(se->compat);
> +}
>  g_free(se->ops);
>  g_free(se);
>  }

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [RFC PATCH v1 2/6] migration: Introduce unregister_savevm_live()

[David Gibson]

On Wed, May 17, 2017 at 09:19:18AM +0530, Bharata B Rao wrote:
> Introduce a new function unregister_savevm_live() to unregister the vmstate
> handlers registered via register_savevm_live().
> 
> register_savevm() allocates SaveVMHandlers while register_savevm_live()
> gets passed with SaveVMHandlers. During unregistration, we  want to
> free SaveVMHandlers in the former case but not free in the latter case.
> Hence this new API is needed to differentiate this.
> 
> This new API will be needed by PowerPC to unregister the HTAB savevm
> handlers.
> 
> Signed-off-by: Bharata B Rao 

It's not my bailiwick, so I don't get final say, but I dislike
changing the signature of the existing unregister_savevm() interface.
I think it would be preferable to only add the 'live' paramter to a
new unregister_savevm_common() (or whatever) function.

> ---
>  hw/net/vmxnet3.c|  2 +-
>  hw/s390x/s390-skeys.c   |  2 +-
>  include/migration/vmstate.h |  4 +++-
>  migration/savevm.c  | 12 ++--
>  slirp/slirp.c   |  2 +-
>  5 files changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
> index 8b1fab2..2b923be 100644
> --- a/hw/net/vmxnet3.c
> +++ b/hw/net/vmxnet3.c
> @@ -2350,7 +2350,7 @@ static void vmxnet3_pci_uninit(PCIDevice *pci_dev)
>  
>  VMW_CBPRN("Starting uninit...");
>  
> -unregister_savevm(dev, "vmxnet3-msix", s);
> +unregister_savevm(dev, "vmxnet3-msix", s, false);
>  
>  vmxnet3_net_uninit(s);
>  
> diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
> index e2d4e1a..32b6435 100644
> --- a/hw/s390x/s390-skeys.c
> +++ b/hw/s390x/s390-skeys.c
> @@ -379,7 +379,7 @@ static inline void 
> s390_skeys_set_migration_enabled(Object *obj, bool value,
>  register_savevm(NULL, TYPE_S390_SKEYS, 0, 1, s390_storage_keys_save,
>  s390_storage_keys_load, ss);
>  } else {
> -unregister_savevm(DEVICE(ss), TYPE_S390_SKEYS, ss);
> +unregister_savevm(DEVICE(ss), TYPE_S390_SKEYS, ss, false);
>  }
>  }
>  
> diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
> index f4bf3f1..ba81b3e 100644
> --- a/include/migration/vmstate.h
> +++ b/include/migration/vmstate.h
> @@ -78,7 +78,9 @@ int register_savevm_live(DeviceState *dev,
>   SaveVMHandlers *ops,
>   void *opaque);
>  
> -void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque);
> +void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque,
> +   bool live);
> +void unregister_savevm_live(DeviceState *dev, const char *idstr, void 
> *opaque);
>  
>  typedef struct VMStateInfo VMStateInfo;
>  typedef struct VMStateDescription VMStateDescription;
> diff --git a/migration/savevm.c b/migration/savevm.c
> index 7a268ec..fa7c3db 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -630,7 +630,8 @@ int register_savevm(DeviceState *dev,
>  ops, opaque);
>  }
>  
> -void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque)
> +void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque,
> +   bool live)
>  {
>  SaveStateEntry *se, *new_se;
>  char id[256] = "";
> @@ -651,12 +652,19 @@ void unregister_savevm(DeviceState *dev, const char 
> *idstr, void *opaque)
>  if (dev) {
>  g_free(se->compat);
>  }
> -g_free(se->ops);
> +if (!live) {
> +g_free(se->ops);
> +}
>  g_free(se);
>  }
>  }
>  }
>  
> +void unregister_savevm_live(DeviceState *dev, const char *idstr, void 
> *opaque)
> +{
> +unregister_savevm(dev, idstr, opaque, true);
> +}
> +
>  int vmstate_register_with_alias_id(DeviceState *dev, int instance_id,
> const VMStateDescription *vmsd,
> void *opaque, int alias_id,
> diff --git a/slirp/slirp.c b/slirp/slirp.c
> index 2f2ec2c..108e669 100644
> --- a/slirp/slirp.c
> +++ b/slirp/slirp.c
> @@ -333,7 +333,7 @@ void slirp_cleanup(Slirp *slirp)
>  {
>  QTAILQ_REMOVE(&slirp_instances, slirp, entry);
>  
> -unregister_savevm(NULL, "slirp", slirp);
> +unregister_savevm(NULL, "slirp", slirp, false);
>  
>  ip_cleanup(slirp);
>  ip6_cleanup(slirp);

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [RFC PATCH v1 6/6] spapr: Fix migration of Radix guests

[David Gibson]

On Wed, May 17, 2017 at 09:19:22AM +0530, Bharata B Rao wrote:
> Fix migration of radix guests by ensuring that we issue
> KVM_PPC_CONFIGURE_V3_MMU for radix case post migration.
> 
> Reported-by: Nageswara R Sastry 
> Signed-off-by: Bharata B Rao 
> ---
>  hw/ppc/spapr.c | 15 +++
>  hw/ppc/spapr_hcall.c   |  1 +
>  include/hw/ppc/spapr.h |  1 +
>  3 files changed, 17 insertions(+)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 05abfc1..dd1d687 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1443,6 +1443,20 @@ static int spapr_post_load(void *opaque, int 
> version_id)
>  err = spapr_rtc_import_offset(&spapr->rtc, spapr->rtc_offset);
>  }
>  
> +if (spapr->patb_entry) {
> +if (kvmppc_has_cap_mmu_radix() && kvm_enabled()) {
> +err = kvmppc_configure_v3_mmu(POWERPC_CPU(first_cpu),
> +  spapr->patb_flags &
> +  SPAPR_PROC_TABLE_RADIX,
> +  spapr->patb_flags &
> +  SPAPR_PROC_TABLE_GTSE,

You should be able to work out the things you need here from
patb_entry without adding the new patb_flags field.

> +  spapr->patb_entry);
> +} else {
> +error_report("Radix guest is unsupported by the host");
> +return -EINVAL;
> +}
> +}
> +
>  return err;
>  }
>  
> @@ -1527,6 +1541,7 @@ static const VMStateDescription 
> vmstate_spapr_patb_entry = {
>  .needed = spapr_patb_entry_needed,
>  .fields = (VMStateField[]) {
>  VMSTATE_UINT64(patb_entry, sPAPRMachineState),
> +VMSTATE_UINT64(patb_flags, sPAPRMachineState),
>  VMSTATE_END_OF_LIST()
>  },
>  };
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 768aa57..b002fae 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -986,6 +986,7 @@ static target_ulong h_register_process_table(PowerPCCPU 
> *cpu,
>  spapr_check_setup_free_hpt(spapr, spapr->patb_entry, cproc);
>  
>  spapr->patb_entry = cproc; /* Save new process table */
> +spapr->patb_flags = flags; /* Save the flags */
>  
>  /* Update the UPRT and GTSE bits in the LPCR for all cpus */
>  CPU_FOREACH(cs) {
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 5b39a26..c25a32e 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -75,6 +75,7 @@ struct sPAPRMachineState {
>  void *htab;
>  uint32_t htab_shift;
>  uint64_t patb_entry; /* Process tbl registed in H_REGISTER_PROCESS_TABLE 
> */
> +uint64_t patb_flags;
>  hwaddr rma_size;
>  int vrma_adjust;
>  ssize_t rtas_size;

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v3] net/rocker: Convert to realize

[Markus Armbruster]

Mao Zhongyi  writes:

> Hi, Markus
>
> On 05/16/2017 11:29 PM, Markus Armbruster wrote:
>> Mao Zhongyi  writes:
>>
>>> The rocker device still implements the old PCIDeviceClass .init()
>>> instead of the new .realize(). All devices need to be converted to
>>> .realize().
>>
>> Thanks for chipping in!
>>
>>> .init() reports errors with fprintf() and return 0 on success, negative
>>> number on failure. Meanwhile, when -device rocker fails, it first report
>>> a specific error, then a generic one, like this:
>>>
>>> $ x86_64-softmmu/qemu-system-x86_64 -device rocker,name=qemu-rocker
>>> rocker: name too long; please shorten to at most 9 chars
>>> qemu-system-x86_64: -device rocker,name=qemu-rocker: Device 
>>> initialization failed
>>>
>>> Now, convert it to .realize() that passes errors to its callers via its
>>> errp argument. Also avoid the superfluous second error message.
>>
>> Recommend to show the error message after your patch here:
>>
>>   qemu-system-x86_64: -device rocker,name=qemu-rocker: rocker: name too 
>> long; please shorten to at most 9 chars
>
> Thanks, I think I got it.
>
>>
>> Not least because that makes it blatantly obvious that keeping the
>> "rocker: " is not a good idea :)
>
> Actually, I was always curious about why there are 2 "rocker" strings
> in the report, it's superfluous. But in order to keep a consistent log
> format, so inherited the original style.
>
> Will remove it in the next version.
>
>>
>>> Cc: j...@resnulli.us
>>> Cc: jasow...@redhat.com
>>> Cc: f4...@amsat.org
>>> Signed-off-by: Mao Zhongyi 
>>> ---
>>>  hw/net/rocker/rocker.c | 35 +--
>>>  1 file changed, 17 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
>>> index 6e70fdd..c446cda 100644
>>> --- a/hw/net/rocker/rocker.c
>>> +++ b/hw/net/rocker/rocker.c
>>> @@ -1252,20 +1252,18 @@ rollback:
>>>  return err;
>>>  }
>>>
>>> -static int rocker_msix_init(Rocker *r)
>>> +static int rocker_msix_init(Rocker *r, Error **errp)
>>>  {
>>>  PCIDevice *dev = PCI_DEVICE(r);
>>>  int err;
>>> -Error *local_err = NULL;
>>>
>>>  err = msix_init(dev, ROCKER_MSIX_VEC_COUNT(r->fp_ports),
>>>  &r->msix_bar,
>>>  ROCKER_PCI_MSIX_BAR_IDX, ROCKER_PCI_MSIX_TABLE_OFFSET,
>>>  &r->msix_bar,
>>>  ROCKER_PCI_MSIX_BAR_IDX, ROCKER_PCI_MSIX_PBA_OFFSET,
>>> -0, &local_err);
>>> +0, errp);
>>>  if (err) {
>>> -error_report_err(local_err);
>>>  return err;
>>>  }
>>>
>>> @@ -1301,7 +1299,7 @@ static World *rocker_world_type_by_name(Rocker *r, 
>>> const char *name)
>>>  return NULL;
>>>  }
>>>
>>> -static int pci_rocker_init(PCIDevice *dev)
>>> +static void pci_rocker_realize(PCIDevice *dev, Error **errp)
>>>  {
>>>  Rocker *r = to_rocker(dev);
>>>  const MACAddr zero = { .a = { 0, 0, 0, 0, 0, 0 } };
>>> @@ -1315,7 +1313,7 @@ static int pci_rocker_init(PCIDevice *dev)
>>>
>>>  for (i = 0; i < ROCKER_WORLD_TYPE_MAX; i++) {
>>>  if (!r->worlds[i]) {
>>> -err = -ENOMEM;
>>> +error_setg(errp, "rocker: memory allocation for worlds 
>>> failed");
>>
>> r->worlds[i] is null when of_dpa_world_alloc() returns null.  It's a
>> wrapper around world_alloc(), which returns null only when g_malloc()
>> does.  It doesn't.  Please remove the dead error handling.  Ideally in a
>> separate cleanup patch before this one, to facilitate review.
>>
>
> Thanks very much for your detailed explanation.
>
> After reading g_malloc0(), I am aware of this: g_malloc0(size_t size)
> returns null only when size is 0. But it is a wrapper around
> g_malloc0_n(1, size) that ignore the fact that g_malloc0() of 0 bytes
> returns null. So it doesn't return null. Am I right?

Correct, it can't return null here.

Aside: even when it does return null for zero size, that null is *not*
an error!

>> Recommend to drop the "rocker: " prefix.  Same for all the other error
>> messages.
>>
>
> Thanks, will dorp it entirely.
>
>>>  goto err_world_alloc;
>>>  }
>>>  }
>>> @@ -1326,10 +1324,9 @@ static int pci_rocker_init(PCIDevice *dev)
>>>
>>>  r->world_dflt = rocker_world_type_by_name(r, r->world_name);
>>>  if (!r->world_dflt) {
>>> -fprintf(stderr,
>>> -"rocker: requested world \"%s\" does not exist\n",
>>> +error_setg(errp,
>>> +"rocker: invalid argument, requested world %s does not 
>>> exist",
>>>  r->world_name);
>>> -err = -EINVAL;
>>>  goto err_world_type_by_name;
>>>  }
>>>
>>> @@ -1349,7 +1346,7 @@ static int pci_rocker_init(PCIDevice *dev)
>>>
>>>  /* MSI-X init */
>>>
>>> -err = rocker_msix_init(r);
>>> +err = rocker_msix_init(r, errp);
>>>  if (err) {
>>>  goto err_msix_init;
>>>  }
>>> @@ -1361,7 +1358,7 @@ static int pci_rocker_init

Re: [Qemu-devel] [RFC PATCH v1 5/6] spapr: Unregister HPT savevm handlers for radix guests

[David Gibson]

On Wed, May 17, 2017 at 09:19:21AM +0530, Bharata B Rao wrote:
> HPT gets created by default and later when the guest turns out to be
> a radix guest, the HPT is destroyed when guest does H_REGISTER_PROC_TBL
> hcall.

I don't think that's entirely accurate.  At least in some KVM
configurations, we assume radix first, and only allocate the HPT once
the guest confirms it is doing hash.

> Let HTAB savevm handlers registration and unregistration follow
> the same model so that we don't end up having unrequired HTAB savevm
> handlers for radix guests.
> 
> This also ensures that HTAB savevm handlers seemlessly get destroyed and
> recreated like HTAB itself when hash guest reboots.
> 
> Signed-off-by: Bharata B Rao 
> ---
>  hw/ppc/spapr.c | 15 +--
>  hw/ppc/spapr_hcall.c   |  1 +
>  include/hw/ppc/spapr.h |  2 ++
>  3 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 521eef1..05abfc1 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1237,6 +1237,7 @@ static void spapr_reallocate_hpt(sPAPRMachineState 
> *spapr, int shift,
>  
>  /* Clean up any HPT info from a previous boot */
>  spapr_free_hpt(spapr);
> +spapr_htab_savevm_unregister(spapr);

I'd prefer that the unregister be folded into spapr_free_hpt().
Basically we want calls that create or remove the HPT and handle
everything - allocation/freeing if necessary, informing KVM if
necessary, and registering/deregistering the savevm handlers if
necesary.

I think that will also remove the need for the trivial
spapr_htab_savevm_{un,}register() wrappers.

>  
>  rc = kvmppc_reset_htab(shift);
>  if (rc < 0) {
> @@ -1275,6 +1276,7 @@ static void spapr_reallocate_hpt(sPAPRMachineState 
> *spapr, int shift,
>  DIRTY_HPTE(HPTE(spapr->htab, i));
>  }
>  }
> +spapr_htab_savevm_register(spapr);
>  }
>  
>  void spapr_setup_hpt_and_vrma(sPAPRMachineState *spapr)
> @@ -1874,6 +1876,17 @@ static SaveVMHandlers savevm_htab_handlers = {
>  .load_state = htab_load,
>  };
>  
> +void spapr_htab_savevm_register(sPAPRMachineState *spapr)
> +{
> +register_savevm_live(NULL, "spapr/htab", -1, 1,
> + &savevm_htab_handlers, spapr);
> +}
> +
> +void spapr_htab_savevm_unregister(sPAPRMachineState *spapr)
> +{
> +unregister_savevm_live(NULL, "spapr/htab", spapr);
> +}
> +
>  static void spapr_boot_set(void *opaque, const char *boot_device,
> Error **errp)
>  {
> @@ -2336,8 +2349,6 @@ static void ppc_spapr_init(MachineState *machine)
>   * interface, this is a legacy from the sPAPREnvironment structure
>   * which predated MachineState but had a similar function */
>  vmstate_register(NULL, 0, &vmstate_spapr, spapr);
> -register_savevm_live(NULL, "spapr/htab", -1, 1,
> - &savevm_htab_handlers, spapr);
>  
>  /* used by RTAS */
>  QTAILQ_INIT(&spapr->ccs_list);
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index be79e3d..768aa57 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -914,6 +914,7 @@ static void spapr_check_setup_free_hpt(sPAPRMachineState 
> *spapr,
>  } else if (!(patbe_old & PATBE1_GR)) {
>  /* HASH->RADIX : Free HPT */
>  spapr_free_hpt(spapr);
> +spapr_htab_savevm_unregister(spapr);
>  } else if (!(patbe_new & PATBE1_GR)) {
>  /* RADIX->HASH || NOTHING->HASH : Allocate HPT */
>  spapr_setup_hpt_and_vrma(spapr);
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 6f9cb85..5b39a26 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -636,6 +636,8 @@ void 
> spapr_hotplug_req_remove_by_count_indexed(sPAPRDRConnectorType drc_type,
> uint32_t count, uint32_t 
> index);
>  void *spapr_populate_hotplug_cpu_dt(CPUState *cs, int *fdt_offset,
>  sPAPRMachineState *spapr);
> +void spapr_htab_savevm_register(sPAPRMachineState *spapr);
> +void spapr_htab_savevm_unregister(sPAPRMachineState *spapr);
>  
>  /* rtas-configure-connector state */
>  struct sPAPRConfigureConnectorState {

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [RFC PATCH v1 6/6] spapr: Fix migration of Radix guests

[Bharata B Rao]

On Wed, May 17, 2017 at 05:00:49PM +1000, David Gibson wrote:
> On Wed, May 17, 2017 at 09:19:22AM +0530, Bharata B Rao wrote:
> > Fix migration of radix guests by ensuring that we issue
> > KVM_PPC_CONFIGURE_V3_MMU for radix case post migration.
> > 
> > Reported-by: Nageswara R Sastry 
> > Signed-off-by: Bharata B Rao 
> > ---
> >  hw/ppc/spapr.c | 15 +++
> >  hw/ppc/spapr_hcall.c   |  1 +
> >  include/hw/ppc/spapr.h |  1 +
> >  3 files changed, 17 insertions(+)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 05abfc1..dd1d687 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -1443,6 +1443,20 @@ static int spapr_post_load(void *opaque, int 
> > version_id)
> >  err = spapr_rtc_import_offset(&spapr->rtc, spapr->rtc_offset);
> >  }
> >  
> > +if (spapr->patb_entry) {
> > +if (kvmppc_has_cap_mmu_radix() && kvm_enabled()) {
> > +err = kvmppc_configure_v3_mmu(POWERPC_CPU(first_cpu),
> > +  spapr->patb_flags &
> > +  SPAPR_PROC_TABLE_RADIX,
> > +  spapr->patb_flags &
> > +  SPAPR_PROC_TABLE_GTSE,
> 
> You should be able to work out the things you need here from
> patb_entry without adding the new patb_flags field.

kvmppc_configure_v3_mmu() needs two bools: radix and gtse. The radix
bit can be implied from patb_entry, I needed patb_flags to get the
gtse value. Not immediately obvious of how to get gtse bit from patb_entry,
but let me take a relook.

Regards,
Bharata.

Re: [Qemu-devel] [PATCH 0/4] exec: address space translation cleanups

[Maxime Coquelin]

On 05/17/2017 07:57 AM, Peter Xu wrote:

On Wed, May 17, 2017 at 12:23:42PM +0800, Peter Xu wrote:

On Tue, May 16, 2017 at 06:51:03PM +0200, Maxime Coquelin wrote:

Hi Peter,

On 05/16/2017 03:24 PM, Maxime Coquelin wrote:



On 05/15/2017 10:50 AM, Peter Xu wrote:

The problem is that, address_space_get_iotlb_entry() shares a lot with
address_space_translate(). This patch tries to abstract the
shared elements.

Originally, this work is derived from discussion from VT-d passthrough
series discussions [1]. But for sure we can just see this series as a
standalone cleanup. So I posted it separately here.

Smoke tests are done with general VM boots, IOs, especially with vhost
dmar configurations.

I believe with current series I can throw away the old patch [1],
which may be good. But before that, please kindly review. Thanks.


I faced the problem the old patch fixes when declaring and attaching an
IOMMU device, but booting the kernel with intel_iommu=off.

I tested again with patches 1 & 4 of your series, and I confirm it fixes
the issue:
Tested-by: Maxime Coquelin 


I did some more testing with my "vhost-user IOMMU" setup, and the series
actually breaks with IOMMU device attached, and intel_iommu=on.

The main difference with the previous passing test is the guest RAM
size. In the working setup, it is 2G of 2M hugepages, vs. 4G of 2M
hugepages in the failing one. Note that I also reproduce with vhost-kernel
backend.

The error happens in the first vhost_device_iotlb_miss() call:
qemu-system-x86_64: Fail to lookup the translated address b5d7c000

I don't have the root cause yet, I'll keep you updated.


Maxime,

Thanks a lot for help testing this series!

I reproduced this problem, and this is not a problem obvious enough
for me. Let me investigate as well.

--
Peter Xu


Maxime,

Could you help try adding this change upon current to see whether
problem solved?


Hi Peter,

Yes, problem is solved with below change.

Thanks!
Maxime


diff --git a/exec.c b/exec.c
index 697d902..68576a2 100644
--- a/exec.c
+++ b/exec.c
@@ -521,6 +521,10 @@ IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace 
*as, hwaddr addr,
  goto iotlb_fail;
  }
  
+/* Convert memory region offset into address space offset */

+xlat += section.offset_within_address_space -
+section.offset_within_region;
+
  if (plen == (hwaddr)-1) {
  /*
   * We use default page size here. Logically it only happens

Thanks in advance,

Re: [Qemu-devel] [PATCH v1] target/s390x: Add support for the TEST BLOCK instruction

[Thomas Huth]

On 16.05.2017 15:42, Aurelien Jarno wrote:
> On 2017-05-16 11:28, Thomas Huth wrote:
>> TEST BLOCK was likely once used to execute basic memory
>> tests, but nowadays it's just a (slow) way to clear a page.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  target/s390x/helper.h  |  1 +
>>  target/s390x/insn-data.def |  2 ++
>>  target/s390x/mem_helper.c  | 12 
>>  target/s390x/translate.c   | 10 ++
>>  4 files changed, 25 insertions(+)
>>
>> diff --git a/target/s390x/helper.h b/target/s390x/helper.h
>> index 9102071..a5a3705 100644
>> --- a/target/s390x/helper.h
>> +++ b/target/s390x/helper.h
>> @@ -99,6 +99,7 @@ DEF_HELPER_FLAGS_4(lctl, TCG_CALL_NO_WG, void, env, i32, 
>> i64, i32)
>>  DEF_HELPER_FLAGS_4(lctlg, TCG_CALL_NO_WG, void, env, i32, i64, i32)
>>  DEF_HELPER_FLAGS_4(stctl, TCG_CALL_NO_WG, void, env, i32, i64, i32)
>>  DEF_HELPER_FLAGS_4(stctg, TCG_CALL_NO_WG, void, env, i32, i64, i32)
>> +DEF_HELPER_2(testblock, void, env, i64)
>>  DEF_HELPER_FLAGS_2(tprot, TCG_CALL_NO_RWG, i32, i64, i64)
>>  DEF_HELPER_FLAGS_2(iske, TCG_CALL_NO_RWG_SE, i64, env, i64)
>>  DEF_HELPER_FLAGS_3(sske, TCG_CALL_NO_RWG, void, env, i64, i64)
>> diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.def
>> index 075ff59..a6aba54 100644
>> --- a/target/s390x/insn-data.def
>> +++ b/target/s390x/insn-data.def
>> @@ -912,6 +912,8 @@
>>  /* STORE USING REAL ADDRESS */
>>  C(0xb246, STURA,   RRE,   Z,   r1_o, r2_o, 0, 0, stura, 0)
>>  C(0xb925, STURG,   RRE,   Z,   r1_o, r2_o, 0, 0, sturg, 0)
>> +/* TEST BLOCK */
>> +C(0xb22c, TB,  RRE,   Z,   0, r2_o, 0, 0, testblock, 0)
>>  /* TEST PROTECTION */
>>  C(0xe501, TPROT,   SSE,   Z,   la1, a2, 0, 0, tprot, 0)
>>  
>> diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c
>> index 675aba2..0349c10 100644
>> --- a/target/s390x/mem_helper.c
>> +++ b/target/s390x/mem_helper.c
>> @@ -933,6 +933,18 @@ void HELPER(stctl)(CPUS390XState *env, uint32_t r1, 
>> uint64_t a2, uint32_t r3)
>>  }
>>  }
>>  
>> +void HELPER(testblock)(CPUS390XState *env, uint64_t addr)
>> +{
>> +CPUState *cs = CPU(s390_env_get_cpu(env));
>> +int i;
>> +
>> +addr = get_address(env, 0, 0, addr) & ~0xfffULL;
> 
> I guess you want to use ~TARGET_PAGE_MASK here.

Yes, that's better, thanks!

>> +for (i = 0; i < TARGET_PAGE_SIZE; i += 8) {
>> +stq_phys(cs->as, addr + i, 0);
>> +}
>> +env->cc_op = 0;
>> +}
>> +
> 
> From what I understand the resulting condition code should depends if
> the block is usable or not. Shouldn't there be a check to see if the
> address actually targets the RAM?

I just tried it under z/VM and KVM, and in case you specify an address
that does not point to valid RAM, you get an addressing exception
instead. So the CC=1 case was rather meant for memory blocks of valid
RAM which contain uncorrectable bit flip errors or something like that.
That does not make much sense for emulation, so CC=0 is the only useful
code that we can return here. But of course I've also got to add a check
for valid RAM and return an addressing exception here now, too...

 Thomas

Re: [Qemu-devel] [RFC PATCH v1 5/6] spapr: Unregister HPT savevm handlers for radix guests

[Bharata B Rao]

On Wed, May 17, 2017 at 04:59:33PM +1000, David Gibson wrote:
> On Wed, May 17, 2017 at 09:19:21AM +0530, Bharata B Rao wrote:
> > HPT gets created by default and later when the guest turns out to be
> > a radix guest, the HPT is destroyed when guest does H_REGISTER_PROC_TBL
> > hcall.
> 
> I don't think that's entirely accurate.  At least in some KVM
> configurations, we assume radix first, and only allocate the HPT once
> the guest confirms it is doing hash.

Right, that statement is true for TCG radix guests, will rephrase it.

> 
> > Let HTAB savevm handlers registration and unregistration follow
> > the same model so that we don't end up having unrequired HTAB savevm
> > handlers for radix guests.
> > 
> > This also ensures that HTAB savevm handlers seemlessly get destroyed and
> > recreated like HTAB itself when hash guest reboots.
> > 
> > Signed-off-by: Bharata B Rao 
> > ---
> >  hw/ppc/spapr.c | 15 +--
> >  hw/ppc/spapr_hcall.c   |  1 +
> >  include/hw/ppc/spapr.h |  2 ++
> >  3 files changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 521eef1..05abfc1 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -1237,6 +1237,7 @@ static void spapr_reallocate_hpt(sPAPRMachineState 
> > *spapr, int shift,
> >  
> >  /* Clean up any HPT info from a previous boot */
> >  spapr_free_hpt(spapr);
> > +spapr_htab_savevm_unregister(spapr);
> 
> I'd prefer that the unregister be folded into spapr_free_hpt().
> Basically we want calls that create or remove the HPT and handle
> everything - allocation/freeing if necessary, informing KVM if
> necessary, and registering/deregistering the savevm handlers if
> necesary.
> 
> I think that will also remove the need for the trivial
> spapr_htab_savevm_{un,}register() wrappers.

Sure, will consolidate this in the next version.

Regards,
Bharata.

Re: [Qemu-devel] [RFC PATCH v1 6/6] spapr: Fix migration of Radix guests

[David Gibson]

On Wed, May 17, 2017 at 12:45:39PM +0530, Bharata B Rao wrote:
> On Wed, May 17, 2017 at 05:00:49PM +1000, David Gibson wrote:
> > On Wed, May 17, 2017 at 09:19:22AM +0530, Bharata B Rao wrote:
> > > Fix migration of radix guests by ensuring that we issue
> > > KVM_PPC_CONFIGURE_V3_MMU for radix case post migration.
> > > 
> > > Reported-by: Nageswara R Sastry 
> > > Signed-off-by: Bharata B Rao 
> > > ---
> > >  hw/ppc/spapr.c | 15 +++
> > >  hw/ppc/spapr_hcall.c   |  1 +
> > >  include/hw/ppc/spapr.h |  1 +
> > >  3 files changed, 17 insertions(+)
> > > 
> > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > index 05abfc1..dd1d687 100644
> > > --- a/hw/ppc/spapr.c
> > > +++ b/hw/ppc/spapr.c
> > > @@ -1443,6 +1443,20 @@ static int spapr_post_load(void *opaque, int 
> > > version_id)
> > >  err = spapr_rtc_import_offset(&spapr->rtc, spapr->rtc_offset);
> > >  }
> > >  
> > > +if (spapr->patb_entry) {
> > > +if (kvmppc_has_cap_mmu_radix() && kvm_enabled()) {
> > > +err = kvmppc_configure_v3_mmu(POWERPC_CPU(first_cpu),
> > > +  spapr->patb_flags &
> > > +  SPAPR_PROC_TABLE_RADIX,
> > > +  spapr->patb_flags &
> > > +  SPAPR_PROC_TABLE_GTSE,
> > 
> > You should be able to work out the things you need here from
> > patb_entry without adding the new patb_flags field.
> 
> kvmppc_configure_v3_mmu() needs two bools: radix and gtse. The radix
> bit can be implied from patb_entry, I needed patb_flags to get the
> gtse value. Not immediately obvious of how to get gtse bit from patb_entry,
> but let me take a relook.

Oh, sorry, you can't get GTSE from the patb_entry, but you can get it
from the LPCR.

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [RFC PATCH v1 2/6] migration: Introduce unregister_savevm_live()

[Bharata B Rao]

On Wed, May 17, 2017 at 04:45:44PM +1000, David Gibson wrote:
> On Wed, May 17, 2017 at 09:19:18AM +0530, Bharata B Rao wrote:
> > Introduce a new function unregister_savevm_live() to unregister the vmstate
> > handlers registered via register_savevm_live().
> > 
> > register_savevm() allocates SaveVMHandlers while register_savevm_live()
> > gets passed with SaveVMHandlers. During unregistration, we  want to
> > free SaveVMHandlers in the former case but not free in the latter case.
> > Hence this new API is needed to differentiate this.
> > 
> > This new API will be needed by PowerPC to unregister the HTAB savevm
> > handlers.
> > 
> > Signed-off-by: Bharata B Rao 
> 
> It's not my bailiwick, so I don't get final say, but I dislike
> changing the signature of the existing unregister_savevm() interface.
> I think it would be preferable to only add the 'live' paramter to a
> new unregister_savevm_common() (or whatever) function.

Yeah, much better, let me change this in next version.

Regards,
Bharata.

Re: [Qemu-devel] [RFC PATCH v1 5/6] spapr: Unregister HPT savevm handlers for radix guests

[David Gibson]

On Wed, May 17, 2017 at 12:48:21PM +0530, Bharata B Rao wrote:
> On Wed, May 17, 2017 at 04:59:33PM +1000, David Gibson wrote:
> > On Wed, May 17, 2017 at 09:19:21AM +0530, Bharata B Rao wrote:
> > > HPT gets created by default and later when the guest turns out to be
> > > a radix guest, the HPT is destroyed when guest does H_REGISTER_PROC_TBL
> > > hcall.
> > 
> > I don't think that's entirely accurate.  At least in some KVM
> > configurations, we assume radix first, and only allocate the HPT once
> > the guest confirms it is doing hash.
> 
> Right, that statement is true for TCG radix guests, will rephrase
> it.

And may not remain true even for TCG radix guests.  Since for TCG mode
we don't actually need either an HPT or an RPT while the guest is in
real mode, I've suggested postponing HPT allocation to CAS time for
TCG as well; I think that will make for slightly fewer differeneces
between the KVM and TCG paths.

> > > Let HTAB savevm handlers registration and unregistration follow
> > > the same model so that we don't end up having unrequired HTAB savevm
> > > handlers for radix guests.
> > > 
> > > This also ensures that HTAB savevm handlers seemlessly get destroyed and
> > > recreated like HTAB itself when hash guest reboots.
> > > 
> > > Signed-off-by: Bharata B Rao 
> > > ---
> > >  hw/ppc/spapr.c | 15 +--
> > >  hw/ppc/spapr_hcall.c   |  1 +
> > >  include/hw/ppc/spapr.h |  2 ++
> > >  3 files changed, 16 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > index 521eef1..05abfc1 100644
> > > --- a/hw/ppc/spapr.c
> > > +++ b/hw/ppc/spapr.c
> > > @@ -1237,6 +1237,7 @@ static void spapr_reallocate_hpt(sPAPRMachineState 
> > > *spapr, int shift,
> > >  
> > >  /* Clean up any HPT info from a previous boot */
> > >  spapr_free_hpt(spapr);
> > > +spapr_htab_savevm_unregister(spapr);
> > 
> > I'd prefer that the unregister be folded into spapr_free_hpt().
> > Basically we want calls that create or remove the HPT and handle
> > everything - allocation/freeing if necessary, informing KVM if
> > necessary, and registering/deregistering the savevm handlers if
> > necesary.
> > 
> > I think that will also remove the need for the trivial
> > spapr_htab_savevm_{un,}register() wrappers.
> 
> Sure, will consolidate this in the next version.
> 
> Regards,
> Bharata.
> 

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 0/4] exec: address space translation cleanups

[Paolo Bonzini]

On 17/05/2017 09:17, Maxime Coquelin wrote:
> 
> 
> On 05/17/2017 07:57 AM, Peter Xu wrote:
>> On Wed, May 17, 2017 at 12:23:42PM +0800, Peter Xu wrote:
>>> On Tue, May 16, 2017 at 06:51:03PM +0200, Maxime Coquelin wrote:
 Hi Peter,

 On 05/16/2017 03:24 PM, Maxime Coquelin wrote:
>
>
> On 05/15/2017 10:50 AM, Peter Xu wrote:
>> The problem is that, address_space_get_iotlb_entry() shares a lot
>> with
>> address_space_translate(). This patch tries to abstract the
>> shared elements.
>>
>> Originally, this work is derived from discussion from VT-d
>> passthrough
>> series discussions [1]. But for sure we can just see this series as a
>> standalone cleanup. So I posted it separately here.
>>
>> Smoke tests are done with general VM boots, IOs, especially with
>> vhost
>> dmar configurations.
>>
>> I believe with current series I can throw away the old patch [1],
>> which may be good. But before that, please kindly review. Thanks.
>
> I faced the problem the old patch fixes when declaring and
> attaching an
> IOMMU device, but booting the kernel with intel_iommu=off.
>
> I tested again with patches 1 & 4 of your series, and I confirm it
> fixes
> the issue:
> Tested-by: Maxime Coquelin 

 I did some more testing with my "vhost-user IOMMU" setup, and the
 series
 actually breaks with IOMMU device attached, and intel_iommu=on.

 The main difference with the previous passing test is the guest RAM
 size. In the working setup, it is 2G of 2M hugepages, vs. 4G of 2M
 hugepages in the failing one. Note that I also reproduce with
 vhost-kernel
 backend.

 The error happens in the first vhost_device_iotlb_miss() call:
 qemu-system-x86_64: Fail to lookup the translated address b5d7c000

 I don't have the root cause yet, I'll keep you updated.
>>>
>>> Maxime,
>>>
>>> Thanks a lot for help testing this series!
>>>
>>> I reproduced this problem, and this is not a problem obvious enough
>>> for me. Let me investigate as well.
>>>
>>> -- 
>>> Peter Xu
>>
>> Maxime,
>>
>> Could you help try adding this change upon current to see whether
>> problem solved?
> 
> Hi Peter,
> 
> Yes, problem is solved with below change.

Cool---Peter, please send the new patch 4 as toplevel message!

Thanks,

Paolo

Re: [Qemu-devel] [PATCH] ivshmem-server: Detect and use if there is required -lrt linking

[Markus Armbruster]

Kamil Rytarowski  writes:

> ivshmem-server makes use of the POSIX shared memory object interfaces.
> This library is provided on NetBSD in -lrt (POSIX Real-time Library).
> Add ./configure check if there is needed -lrt linking for shm_open()
> and if so use it. Introduce new configure generated variable LIBS_SHMLIB.
>
> This fixes build issue on NetBSD.
>
> Signed-off-by: Kamil Rytarowski 
> ---
>  Makefile  |  1 +
>  configure | 20 
>  2 files changed, 21 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 31d41a7eae..3248cb53d7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -473,6 +473,7 @@ ivshmem-client$(EXESUF): $(ivshmem-client-obj-y) 
> $(COMMON_LDADDS)
>   $(call LINK, $^)
>  ivshmem-server$(EXESUF): $(ivshmem-server-obj-y) $(COMMON_LDADDS)
>   $(call LINK, $^)
> +ivshmem-server$(EXESUF): LIBS += $(LIBS_SHMLIB)
>  
>  module_block.h: $(SRC_PATH)/scripts/modules/module_block.py config-host.mak
>   $(call quiet-command,$(PYTHON) $< $@ \
> diff --git a/configure b/configure
> index 7c020c076b..50c3aee746 100755
> --- a/configure
> +++ b/configure
> @@ -179,6 +179,7 @@ audio_pt_int=""
>  audio_win_int=""
>  cc_i386=i386-pc-linux-gnu-gcc
>  libs_qga=""
> +libs_shmlib=""
>  debug_info="yes"
>  stack_protector=""
>  
> @@ -4133,6 +4134,24 @@ elif compile_prog "" "$pthread_lib -lrt" ; then
>libs_qga="$libs_qga -lrt"
>  fi
>  
> +##
> +# Do we need librt for shm_open()
> +cat > $TMPC < +#include 
> +#include 
> +#include 
> +#include 
> +int main(void) {
> +  return shm_open(NULL, O_RDWR, 0644);
> +}
> +EOF
> +
> +if compile_prog "" "" ; then
> +  :
> +elif compile_prog "" "-lrt" ; then
> +  libs_shmlib="$libs_shmlib -lrt"
> +fi
> +
>  if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a \
>  "$aix" != "yes" -a "$haiku" != "yes" ; then
>  libs_softmmu="-lutil $libs_softmmu"
> @@ -5949,6 +5968,7 @@ echo "EXESUF=$EXESUF" >> $config_host_mak
>  echo "DSOSUF=$DSOSUF" >> $config_host_mak
>  echo "LDFLAGS_SHARED=$LDFLAGS_SHARED" >> $config_host_mak
>  echo "LIBS_QGA+=$libs_qga" >> $config_host_mak
> +echo "LIBS_SHMLIB+=$libs_shmlib" >> $config_host_mak
>  echo "TASN1_LIBS=$tasn1_libs" >> $config_host_mak
>  echo "TASN1_CFLAGS=$tasn1_cflags" >> $config_host_mak
>  echo "POD2MAN=$POD2MAN" >> $config_host_mak

We already have a test for -lrt.  It looks for timer_create() and
clock_gettime().  If we need -lrt, we add it to LIBS and to LIBS_QGA.
The latter because we don't use LIBS for qemu-ga:

qemu-ga$(EXESUF): LIBS = $(LIBS_QGA)

This patch adds a second test for -lrt, to look for shm_open().  It adds
-lrt to new variable LIBS_SHMLIB, which gets used only for
ivshmem-server:

ivshmem-server$(EXESUF): LIBS += $(LIBS_SHMLIB)

Note that ivshmem-server already uses LIBS.

Shouldn't we instead widen the existing test for -lrt to cover
shm_open()?

Can you confirm that the existing test does not add -lrt to LIBS on
NetBSD?

tests/ivshmem-test.c also calls shm_open().  Does it work on NetBSD?

Re: [Qemu-devel] 答复： Re: [RFC] virtio-fc: draft idea of virtual fibre channel HBA

[Paolo Bonzini]

On 17/05/2017 08:01, Hannes Reinecke wrote:
> On 05/16/2017 06:22 PM, Paolo Bonzini wrote:
>> On 16/05/2017 17:22, Hannes Reinecke wrote:
>>> iSCSI has its 'iqn' string, which is defined to be a 256-byte string.
>>> Hence the number 
>>> And if we're updating virtio anyway, we could as well update it to carry
>>> _all_ possible scsi IDs.
>>
>> Yes, but one iSCSI connection maps to one initiator and target IQN.
>> It's not like FC where each frame can specify its own initiator ID.
>>
> Sure. But updating the format to hold _any_ SCSI Name would allow us to
> reflect the actual initiator port name used by the host.
> So the guest could be

... aware of it for things such as PERSISTENT RESERVE IN?

> (3) would be feasible, as it would effectively mean 'just' to update the
> current NPIV mechanism. However, this would essentially lock us in for
> FC; any other types (think NVMe) will require yet another solution.
 An FC-NVMe driver could also expose the same vhost interface, couldn't it?
 FC-NVMe doesn't have to share the Linux code; but sharing the virtio 
 standard
 and the userspace ABI would be great.

 In fact, the main advantage of virtio-fc would be that (if we define it 
 properly)
 it could be reused for FC-NVMe instead of having to extend e.g. virtio-blk.
 For example virtio-scsi has request, to-device payload, response, 
 from-device
 payload.  virtio-fc's request format could be the initiator and target port
 identifiers, followed by FCP_CMD, to-device payload, FCP_RSP, from-device
 payload.

>>> As already said: We do _not_ have access to the FCP frames.
>>> So designing a virtio-fc protocol will only work for libfc-based HBAs,
>>> namely fnic, bnx2fc, and fcoe.
>>> Given that the future of FCoE is somewhat unclear I doubt it's a good
>>> idea to restrict ourselves to that.
>>
>> I understand that.  It doesn't have to be a 1:1 match with FCP frames or
>> even IUs; in fact the above minimal example is not (no OXID/RXID and no
>> FCP_XFER_RDY IU are just the first two things that come to mind).
>>
>> The only purpose is to have a *transport* that is (roughly speaking)
>> flexible enough to support future NPIV usecases which will certainly
>> include FC-NVMe.  In other words: I'm inventing my own cooked FCP
>> format, but I might as well base it on FCP itself as much as possible.
>
> Weeelll ... I don't want to go into nit-picking here, but FC-NVMe is
> _NOT_ FCP. In fact, it's a different FC-4 provider with its own set of
> FC-4 commands etc.

Yes, but it reuses the IU format and the overall look of the exchange.
It's not FCP, but it looks and quacks very much like it AFAIU.

>> Likewise, I'm not going to even mention ELS, but we would need _some_
>> kind of protocol to query name servers, receive state change
>> notifications, and get service parameters.  No idea yet how to do that,
>> probably something similar to virtio-scsi control and event queues, but
>> why not make the requests/responses look a little like PLOGI and PRLI?
>>
> And my idea here is to keep virtio-scsi as the basic mode of (command)
> transfer, but add a set of transport management commands which would
> allow us to do things like:
> - port discovery / scan
> - port instantiation / login
> - port reset
> - transport link notification / status check
> - transport reset
> 
> Those could be defined transport independently; and the neat thing is
> they could even be made to work with the current NPIV implementation
> with some tooling.
> And we could define things such that all current transport protocols can
> be mapped onto it.

Okay, got it.  So some kind of virtio-scsi 2.0.  I think we should weigh
the two proposals.  Would yours be useful for anything except NPIV (e.g.
the iSCSI + persistent reservations case)?  What software would use it?
And please speak up loudly if I'm completely mistaken about FC-NVMe!

Thanks,

Paolo

Re: [Qemu-devel] About QEMU BQL and dirty log switch in Migration

[Jay Zhou]

On 2017/5/17 13:47, Wanpeng Li wrote:

Hi Zhoujian,
2017-05-17 10:20 GMT+08:00 Zhoujian (jay) :

Hi Wanpeng,


On 11/05/2017 14:07, Zhoujian (jay) wrote:

-* Scan sptes if dirty logging has been stopped, dropping those
-* which can be collapsed into a single large-page spte.  Later
-* page faults will create the large-page sptes.
+* Reset each vcpu's mmu, then page faults will create the

large-page

+* sptes later.
  */
 if ((change != KVM_MR_DELETE) &&
 (old->flags & KVM_MEM_LOG_DIRTY_PAGES) &&
-   !(new->flags & KVM_MEM_LOG_DIRTY_PAGES))
-   kvm_mmu_zap_collapsible_sptes(kvm, new);


This is an unlikely branch(unless guest live migration fails and continue
to run on the source machine) instead of hot path, do you have any
performance number for your real workloads?



Sorry to bother you again.

Recently, I have tested the performance before migration and after migration 
failure
using spec cpu2006 https://www.spec.org/cpu2006/, which is a standard 
performance
evaluation tool.

These are the results:
**
 Before migration the score is 153, and the TLB miss statistics of the qemu 
process is:
 linux-sjrfac:/mnt/zhoujian # perf stat -e 
dTLB-load-misses,dTLB-loads,dTLB-store-misses, \
 dTLB-stores,iTLB-load-misses,iTLB-loads -p 26463 sleep 10

 Performance counter stats for process id '26463':

698,938  dTLB-load-misses  #0.13% of all dTLB cache 
hits   (50.46%)
543,303,875  dTLB-loads 
   (50.43%)
199,597  dTLB-store-misses  
   (16.51%)
 60,128,561  dTLB-stores
   (16.67%)
 69,986  iTLB-load-misses  #6.17% of all iTLB cache 
hits   (16.67%)
  1,134,097  iTLB-loads 
   (33.33%)

   10.000684064 seconds time elapsed

 After migration failure the score is 149, and the TLB miss statistics of 
the qemu process is:
 linux-sjrfac:/mnt/zhoujian # perf stat -e 
dTLB-load-misses,dTLB-loads,dTLB-store-misses, \
 dTLB-stores,iTLB-load-misses,iTLB-loads -p 26463 sleep 10

 Performance counter stats for process id '26463':

765,400  dTLB-load-misses  #0.14% of all dTLB cache 
hits   (50.50%)
540,972,144  dTLB-loads 
   (50.47%)
207,670  dTLB-store-misses  
   (16.50%)
 58,363,787  dTLB-stores
   (16.67%)
109,772  iTLB-load-misses  #9.52% of all iTLB cache 
hits   (16.67%)
  1,152,784  iTLB-loads 
   (33.32%)

   10.000703078 seconds time elapsed
**


Could you comment out the original "lazy collapse small sptes into
large sptes" codes in the function kvm_arch_commit_memory_region() and
post the results here?



  With the patch below,

diff --git a/source/x86/x86.c b/source/x86/x86.c
index 054a7d3..e0288d5 100644
--- a/source/x86/x86.c
+++ b/source/x86/x86.c
@@ -8548,10 +8548,6 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
 * which can be collapsed into a single large-page spte.  Later
 * page faults will create the large-page sptes.
 */
-   if ((change != KVM_MR_DELETE) &&
-   (old->flags & KVM_MEM_LOG_DIRTY_PAGES) &&
-   !(new->flags & KVM_MEM_LOG_DIRTY_PAGES))
-   kvm_mmu_zap_collapsible_sptes(kvm, new);

/*
 * Set up write protection and/or dirty logging for the new slot.

  After migration failure the score is 148, and the TLB miss statistics 
of the qemu process is:
  linux-sjrfac:/mnt/zhoujian # perf stat -e 
dTLB-load-misses,dTLB-loads,dTLB-store-misses,dTLB-stores,iTLB-load-misses,iTLB-loads 
-p 12432 sleep 10


 Performance counter stats for process id '12432':

 1,052,697  dTLB-load-misses  #0.19% of all 
dTLB cache hits   (50.45%)
   551,828,702  dTLB-loads 
   (50.46%)
   147,228  dTLB-store-misses 
   (16.55%)
60,427,834  dTLB-stores 
   (16.50%)
93,793  iTLB-load-misses  #7.43% of all 
iTLB cache hits   (16.67%)
 1,262,137  iTLB-loads 
   (33.33%)


  10.000709900 seconds time elapsed

  Regards,
  Jay Zhou


Regards,
Wanpeng Li



These are the steps:
==
  (1) the version of kmod is 4.4.11(with slightly modified) and the version of 
qemu is 2.6.0
 (with slightly modified), the kmod is applied with the following patch 
according to
 Paolo's advice:

diff --git a/source/x86/x86.c b/source/x86/x86.c
index 054a7d3..75a4bb3 100644
--- a/source/x

Re: [Qemu-devel] [PATCH] qemu-iotests: Test streaming with missing job ID

[Kashyap Chamarthy]

On Mon, May 15, 2017 at 02:39:40PM +0200, Kevin Wolf wrote:
> This adds a small test for the image streaming error path for failing
> block_job_create(), which would have found the null pointer dereference
> in commit a170a91f.
> 
> Signed-off-by: Kevin Wolf 
> ---
>  tests/qemu-iotests/030 | 4 
>  tests/qemu-iotests/030.out | 4 ++--
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
> index e00c11b..feee861 100755
> --- a/tests/qemu-iotests/030
> +++ b/tests/qemu-iotests/030
> @@ -147,6 +147,10 @@ class TestSingleDrive(iotests.QMPTestCase):
>  result = self.vm.qmp('block-stream', device='nonexistent')
>  self.assert_qmp(result, 'error/class', 'GenericError')
>  
> +def test_job_id_missing(self):
> +result = self.vm.qmp('block-stream', device='mid')
> +self.assert_qmp(result, 'error/class', 'GenericError')
> +

Thanks.

FWIW:

Reviewed-by: Kashyap Chamarthy 

[...]

-- 
/kashyap

Re: [Qemu-devel] About QEMU BQL and dirty log switch in Migration

[Paolo Bonzini]

> Recently, I have tested the performance before migration and after migration 
> failure
> using spec cpu2006 https://www.spec.org/cpu2006/, which is a standard 
> performance
> evaluation tool.
>
> These are the steps:
> ==
>  (1) the version of kmod is 4.4.11(with slightly modified) and the version of
>  qemu is 2.6.0
> (with slightly modified), the kmod is applied with the following patch
> 
> diff --git a/source/x86/x86.c b/source/x86/x86.c
> index 054a7d3..75a4bb3 100644
> --- a/source/x86/x86.c
> +++ b/source/x86/x86.c
> @@ -8550,8 +8550,10 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
>  */
> if ((change != KVM_MR_DELETE) &&
> (old->flags & KVM_MEM_LOG_DIRTY_PAGES) &&
> -   !(new->flags & KVM_MEM_LOG_DIRTY_PAGES))
> -   kvm_mmu_zap_collapsible_sptes(kvm, new);
> +   !(new->flags & KVM_MEM_LOG_DIRTY_PAGES)) {
> +   printk(KERN_ERR "zj make KVM_REQ_MMU_RELOAD request\n");
> +   kvm_make_all_cpus_request(kvm, KVM_REQ_MMU_RELOAD);
> +   }
>  
> /*
>  * Set up write protection and/or dirty logging for the new slot.

Try these modifications to the setup:

1) set up 1G hugetlbfs hugepages and use those for the guest's memory

2) test both without and with the above patch.

Thanks,

Paolo

Re: [Qemu-devel] [PATCH v3] net/rocker: Convert to realize

[Mao Zhongyi]

Hi, Markus

On 05/17/2017 03:04 PM, Markus Armbruster wrote:

Mao Zhongyi  writes:




On 05/16/2017 11:29 PM, Markus Armbruster wrote:

Mao Zhongyi  writes:


The rocker device still implements the old PCIDeviceClass .init()
instead of the new .realize(). All devices need to be converted to
.realize().


Thanks for chipping in!


.init() reports errors with fprintf() and return 0 on success, negative
number on failure. Meanwhile, when -device rocker fails, it first report
a specific error, then a generic one, like this:

$ x86_64-softmmu/qemu-system-x86_64 -device rocker,name=qemu-rocker
rocker: name too long; please shorten to at most 9 chars
qemu-system-x86_64: -device rocker,name=qemu-rocker: Device initialization 
failed

Now, convert it to .realize() that passes errors to its callers via its
errp argument. Also avoid the superfluous second error message.


Recommend to show the error message after your patch here:

  qemu-system-x86_64: -device rocker,name=qemu-rocker: rocker: name too 
long; please shorten to at most 9 chars


Thanks, I think I got it.



Not least because that makes it blatantly obvious that keeping the
"rocker: " is not a good idea :)


Actually, I was always curious about why there are 2 "rocker" strings
in the report, it's superfluous. But in order to keep a consistent log
format, so inherited the original style.

Will remove it in the next version.




Cc: j...@resnulli.us
Cc: jasow...@redhat.com
Cc: f4...@amsat.org
Signed-off-by: Mao Zhongyi 
---
 hw/net/rocker/rocker.c | 35 +--
 1 file changed, 17 insertions(+), 18 deletions(-)

diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
index 6e70fdd..c446cda 100644
--- a/hw/net/rocker/rocker.c
+++ b/hw/net/rocker/rocker.c
@@ -1252,20 +1252,18 @@ rollback:
 return err;
 }

-static int rocker_msix_init(Rocker *r)
+static int rocker_msix_init(Rocker *r, Error **errp)
 {
 PCIDevice *dev = PCI_DEVICE(r);
 int err;
-Error *local_err = NULL;

 err = msix_init(dev, ROCKER_MSIX_VEC_COUNT(r->fp_ports),
 &r->msix_bar,
 ROCKER_PCI_MSIX_BAR_IDX, ROCKER_PCI_MSIX_TABLE_OFFSET,
 &r->msix_bar,
 ROCKER_PCI_MSIX_BAR_IDX, ROCKER_PCI_MSIX_PBA_OFFSET,
-0, &local_err);
+0, errp);
 if (err) {
-error_report_err(local_err);
 return err;
 }

@@ -1301,7 +1299,7 @@ static World *rocker_world_type_by_name(Rocker *r, const 
char *name)
 return NULL;
 }

-static int pci_rocker_init(PCIDevice *dev)
+static void pci_rocker_realize(PCIDevice *dev, Error **errp)
 {
 Rocker *r = to_rocker(dev);
 const MACAddr zero = { .a = { 0, 0, 0, 0, 0, 0 } };
@@ -1315,7 +1313,7 @@ static int pci_rocker_init(PCIDevice *dev)

 for (i = 0; i < ROCKER_WORLD_TYPE_MAX; i++) {
 if (!r->worlds[i]) {
-err = -ENOMEM;
+error_setg(errp, "rocker: memory allocation for worlds failed");


r->worlds[i] is null when of_dpa_world_alloc() returns null.  It's a
wrapper around world_alloc(), which returns null only when g_malloc()
does.  It doesn't.  Please remove the dead error handling.  Ideally in a
separate cleanup patch before this one, to facilitate review.



Thanks very much for your detailed explanation.

After reading g_malloc0(), I am aware of this: g_malloc0(size_t size)
returns null only when size is 0. But it is a wrapper around
g_malloc0_n(1, size) that ignore the fact that g_malloc0() of 0 bytes
returns null. So it doesn't return null. Am I right?


Correct, it can't return null here.

Aside: even when it does return null for zero size, that null is *not*
an error!


Thanks, I see.




Recommend to drop the "rocker: " prefix.  Same for all the other error
messages.



Thanks, will dorp it entirely.


 goto err_world_alloc;
 }
 }
@@ -1326,10 +1324,9 @@ static int pci_rocker_init(PCIDevice *dev)

 r->world_dflt = rocker_world_type_by_name(r, r->world_name);
 if (!r->world_dflt) {
-fprintf(stderr,
-"rocker: requested world \"%s\" does not exist\n",
+error_setg(errp,
+"rocker: invalid argument, requested world %s does not exist",
 r->world_name);
-err = -EINVAL;
 goto err_world_type_by_name;
 }

@@ -1349,7 +1346,7 @@ static int pci_rocker_init(PCIDevice *dev)

 /* MSI-X init */

-err = rocker_msix_init(r);
+err = rocker_msix_init(r, errp);
 if (err) {
 goto err_msix_init;
 }
@@ -1361,7 +1358,7 @@ static int pci_rocker_init(PCIDevice *dev)
 }

 if (rocker_find(r->name)) {
-err = -EEXIST;
+error_setg(errp, "rocker: %s already exists", r->name);
 goto err_duplicate;
 }

@@ -1375,10 +1372,10 @@ static int pci_rocker_init(PCIDevice *dev)
 #define ROCKER_IFNAMSIZ 16
 #define MAX_ROCKER_NAME_LEN  (ROCKER_IFNAMSIZ - 1 - 3 - 3)
 if (strlen(r->name) > MA

[Qemu-devel] QEMU master is broken (was: [PATCH 6/6] opengl: add egl-headless display)

[Thomas Huth]

 Hi,

I can not compile git master anymore on my RHEL 7.3 installation ...
I think it is due to this patch here. I now get:

  CC  ui/egl-headless.o
/home/thuth/devel/qemu/ui/egl-headless.c: In function ‘egl_headless_init’:
/home/thuth/devel/qemu/ui/egl-headless.c:142:5: error: implicit declaration of 
function ‘egl_rendernode_init’ [-Werror=implicit-function-declaration]
 if (egl_rendernode_init(NULL) < 0) {
 ^
/home/thuth/devel/qemu/ui/egl-headless.c:142:5: error: nested extern 
declaration of ‘egl_rendernode_init’ [-Werror=nested-externs]
cc1: all warnings being treated as errors
make: *** [ui/egl-headless.o] Error 1

The problem is likely that the prototype in egl-helpers.h is
protected with some "#ifdef CONFIG_OPENGL_DMABUF" ... so should
the code in egl-headless.c put into such conditionals, too?

 Thomas


On 05.05.2017 12:41, Gerd Hoffmann wrote:
> Add egl-headless user interface.  It doesn't provide a real user
> interface, it only provides opengl support using drm render nodes.
> It will copy back the bits rendered by the guest using virgl back
> to a DisplaySurface and kick the usual display update code paths,
> so spice and vnc and screendump can pick it up.
> 
> Use it this way:
>   qemu -display egl-headless -vnc $display
>   qemu -display egl-headless -spice gl=off,$args
> 
> Note that you should prefer native spice opengl support (-spice
> gl=on) if possible because that delivers better performance.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/ui/console.h |   3 +
>  ui/egl-headless.c| 158 
> +++
>  vl.c |  16 ++
>  ui/Makefile.objs |   1 +
>  4 files changed, 178 insertions(+)
>  create mode 100644 ui/egl-headless.c
> 
> diff --git a/include/ui/console.h b/include/ui/console.h
> index d759338816..7262bef6d3 100644
> --- a/include/ui/console.h
> +++ b/include/ui/console.h
> @@ -527,4 +527,7 @@ static inline void early_gtk_display_init(int opengl)
>  }
>  #endif
>  
> +/* egl-headless.c */
> +void egl_headless_init(void);
> +
>  #endif
> diff --git a/ui/egl-headless.c b/ui/egl-headless.c
> new file mode 100644
> index 00..d8d800f8a6
> --- /dev/null
> +++ b/ui/egl-headless.c
> @@ -0,0 +1,158 @@
> +#include "qemu/osdep.h"
> +#include "qemu-common.h"
> +#include "sysemu/sysemu.h"
> +#include "ui/console.h"
> +#include "ui/egl-helpers.h"
> +#include "ui/egl-context.h"
> +
> +typedef struct egl_dpy {
> +DisplayChangeListener dcl;
> +DisplaySurface *ds;
> +int width, height;
> +GLuint texture;
> +GLuint framebuffer;
> +GLuint blit_texture;
> +GLuint blit_framebuffer;
> +bool y_0_top;
> +} egl_dpy;
> +
> +static void egl_refresh(DisplayChangeListener *dcl)
> +{
> +graphic_hw_update(dcl->con);
> +}
> +
> +static void egl_gfx_update(DisplayChangeListener *dcl,
> +   int x, int y, int w, int h)
> +{
> +}
> +
> +static void egl_gfx_switch(DisplayChangeListener *dcl,
> +   struct DisplaySurface *new_surface)
> +{
> +egl_dpy *edpy = container_of(dcl, egl_dpy, dcl);
> +
> +edpy->ds = new_surface;
> +}
> +
> +static void egl_scanout_disable(DisplayChangeListener *dcl)
> +{
> +egl_dpy *edpy = container_of(dcl, egl_dpy, dcl);
> +
> +edpy->texture = 0;
> +/* XXX: delete framebuffers here ??? */
> +}
> +
> +static void egl_scanout_texture(DisplayChangeListener *dcl,
> +uint32_t backing_id,
> +bool backing_y_0_top,
> +uint32_t backing_width,
> +uint32_t backing_height,
> +uint32_t x, uint32_t y,
> +uint32_t w, uint32_t h)
> +{
> +egl_dpy *edpy = container_of(dcl, egl_dpy, dcl);
> +
> +edpy->texture = backing_id;
> +edpy->y_0_top = backing_y_0_top;
> +
> +/* source framebuffer */
> +if (!edpy->framebuffer) {
> +glGenFramebuffers(1, &edpy->framebuffer);
> +}
> +glBindFramebuffer(GL_FRAMEBUFFER_EXT, edpy->framebuffer);
> +glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,
> +  GL_TEXTURE_2D, edpy->texture, 0);
> +
> +/* dest framebuffer */
> +if (!edpy->blit_framebuffer) {
> +glGenFramebuffers(1, &edpy->blit_framebuffer);
> +glGenTextures(1, &edpy->blit_texture);
> +edpy->width = 0;
> +edpy->height = 0;
> +}
> +if (edpy->width != backing_width || edpy->height != backing_height) {
> +edpy->width   = backing_width;
> +edpy->height  = backing_height;
> +glBindTexture(GL_TEXTURE_2D, edpy->blit_texture);
> +glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB,
> + edpy->width, edpy->height,
> + 0, GL_BGRA, GL_UNSIGNED_BYTE, 0);
> +glBindFramebuffer(GL_FRAMEBUFFER_EXT, edpy->blit_framebuffer);
> +glFramebufferTexture2DEXT

[Qemu-devel] [Bug 1691379] [NEW] NetBSD evbmips64el port installation doesn't work with qemu-system-mips64el.

[Utkarsh Anand]

Public bug reported:

I successfully installed the NetBSD evbmips64el port on gxemul but was
unable to install it on qemu. Trying to boot it on qemu takes me to the
'db>' prompt. Here's the output and backtrace:

panic: pcib_isa_intr_string: bogus isa irq 0x0
kernel: breakpoint trap
Stopped in pid 0.1 (system) at  netbsd:cpu_Debugger+0x4:jr  ra
bdslot: nop
db> bt
0x805977f0: cpu_Debugger+4 (63061,9000180003f8,6,804c2290) 
ra 8030acd0 sz 0
0x805977f0: vpanic+158 (63061,9000180003f8,6,804c2290) ra 
8030ad7c sz 64
0x80597830: panic+34 (63061,803d65b0,0,40) ra 80109784 
sz 96
0x80597890: pcib_isa_intr_string+6c (63061,803d65b0,0,40) ra 
80149bfc sz 16
0x805978a0: uhci_pci_attach+16c (63061,803d65b0,0,40) ra 
802f0400 sz 176
0x80597950: config_attach_loc+1c8 (63061,803d65b0,0,40) ra 
802f053c sz 64
0x80597990: config_found_sm_loc+5c (63061,803d65b0,0,40) ra 
80121354 sz 64
0x805979d0: pci_probe_device+524 (63061,803d65b0,0,0) ra 
80121548 sz 288
0x80597af0: pci_enumerate_bus+1d0 (63061,803d65b0,0,0) ra 
8012167c sz 160
0x80597b90: pcirescan+5c (63061,803d65b0,0,0) ra 
801218c4 sz 32
0x80597bb0: pciattach+19c (63061,803d65b0,0,0) ra 
802f0400 sz 80
0x80597c00: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
802f053c sz 64
0x80597c40: config_found_sm_loc+5c (63061,803d65b0,0,0) ra 
80108934 sz 64
0x80597c80: gt_attach+7c (63061,803d65b0,0,0) ra 
802f0400 sz 112   
0x80597cf0: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
802f053c sz 64
0x80597d30: config_found_sm_loc+5c (63061,803d65b0,0,0) ra 
801086ac sz 64
0x80597d70: mainbus_attach+dc (63061,803d65b0,0,0) ra 
802f0400 sz 96
0x80597dd0: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
80104bf8 sz 64
0x80597e10: cpu_configure+28 (63061,803d65b0,0,0) ra 
803d5f30 sz 16
0x80597e20: main+3a0 (63061,803d65b0,0,0) ra 801000dc 
sz 128   
0x80597ea0: kernel_text+dc (63061,803d65b0,0,0) ra 0 sz 0
User-level: pid 0.1

Here's the command that I used:

Build evbmips64el from source and then launch it from qemu (replace the
paths relative to your system):

qemu-system-mips64el -cdrom
/extra/evbmips64/distrib/evbmips/cdroms/installcd/NetBSD-7.99.71
-evbmips-mips64el.iso -hda /extra/evbmips64.img -kernel
/extra/evbmips64/releasedir/evbmips/installation/netbsd-INSTALL_MALTA64
-nographic -M malta

(I've decompressed the kernel)

Here's the output for qemu-system-mips64el --version :

QEMU emulator version 2.7.1(qemu-2.7.1-6.fc25), Copyright (c) 2003-2016
Fabrice Bellard and the QEMU Project developers

This doesn't look like a NetBSD bug. I've attached a screenshot of the
working installation using gxemul in the attachments.

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: mips64el netbsd

** Attachment added: "working installation in gxemul"
   https://bugs.launchpad.net/bugs/1691379/+attachment/4878063/+files/pr4.png

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

Title:
  NetBSD evbmips64el port installation doesn't work with qemu-system-
  mips64el.

Status in QEMU:
  New

Bug description:
  I successfully installed the NetBSD evbmips64el port on gxemul but was
  unable to install it on qemu. Trying to boot it on qemu takes me to
  the 'db>' prompt. Here's the output and backtrace:

  panic: pcib_isa_intr_string: bogus isa irq 0x0
  kernel: breakpoint trap
  Stopped in pid 0.1 (system) at  netbsd:cpu_Debugger+0x4:jr  ra
  bdslot: nop
  db> bt
  0x805977f0: cpu_Debugger+4 
(63061,9000180003f8,6,804c2290) ra 8030acd0 sz 0
  0x805977f0: vpanic+158 (63061,9000180003f8,6,804c2290) ra 
8030ad7c sz 64
  0x80597830: panic+34 (63061,803d65b0,0,40) ra 
80109784 sz 96
  0x80597890: pcib_isa_intr_string+6c (63061,803d65b0,0,40) ra 
80149bfc sz 16
  0x805978a0: uhci_pci_attach+16c (63061,803d65b0,0,40) ra 
802f0400 sz 176
  0x80597950: config_attach_loc+1c8 (63061,803d65b0,0,40) ra 
802f053c sz 64
  0x80597990: config_found_sm_loc+5c (63061,803d65b0,0,40) ra 
80121354 sz 64
  0x805979d0: pci_probe_device+524 (63061,803d65b0,0,0) ra 
80121548 sz 288
  0x80597af0: pci_enumerate_bus+1d0 (63061,803d65b0,0,0) ra 
8012167c sz 160
  0x80597b90: pcirescan+5c (63061,803d65b0,0

Re: [Qemu-devel] [PATCH] qapi-schema: Remove obsolete note from ObjectTypeInfo

[Markus Armbruster]

Eduardo Habkost  writes:

> The "This command is experimental" note in ObjectTypeInfo is obsolete
> since 2012.  Commit 5192082097549c5b3aa7c913c6853d97a68172cb removed the
> warning from the qom-list-types command documentation, but we forgot to
> remove the warning from ObjectTypeInfo.
>
> Signed-off-by: Eduardo Habkost 

Applied to qapi-next, thanks!

Re: [Qemu-devel] [PULL 23/29] numa: use possible_cpus for not mapped CPUs check

[Markus Armbruster]

Eduardo Habkost  writes:

> From: Igor Mammedov 
>
> and remove corresponding part in numa.c that uses
> node_cpu bitmaps.
>
> Signed-off-by: Igor Mammedov 
> Reviewed-by: David Gibson 
> Reviewed-by: Andrew Jones 
> Message-Id: <1494415802-227633-16-git-send-email-imamm...@redhat.com>
> Signed-off-by: Eduardo Habkost 
> ---
>  hw/core/machine.c | 58 
> +++
>  numa.c| 10 --
>  2 files changed, 58 insertions(+), 10 deletions(-)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 64e2a4ff2c..fd6a436064 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -20,6 +20,7 @@
>  #include "sysemu/numa.h"
>  #include "qemu/error-report.h"
>  #include "qemu/cutils.h"
> +#include "sysemu/numa.h"
>  
>  static char *machine_get_accel(Object *obj, Error **errp)
>  {
> @@ -678,9 +679,66 @@ bool machine_mem_merge(MachineState *machine)
>  return machine->mem_merge;
>  }
>  
> +static char *cpu_slot_to_string(const CPUArchId *cpu)
> +{
> +GString *s = g_string_new(NULL);
> +if (cpu->props.has_socket_id) {
> +g_string_append_printf(s, "socket-id: %"PRId64, 
> cpu->props.socket_id);
> +}
> +if (cpu->props.has_core_id) {
> +if (s->len) {
> +g_string_append_printf(s, ", ");
> +}
> +g_string_append_printf(s, "core-id: %"PRId64, cpu->props.core_id);
> +}
> +if (cpu->props.has_thread_id) {
> +if (s->len) {
> +g_string_append_printf(s, ", ");
> +}
> +g_string_append_printf(s, "thread-id: %"PRId64, 
> cpu->props.thread_id);
> +}
> +return g_string_free(s, false);
> +}
> +
> +static void machine_numa_validate(MachineState *machine)
> +{
> +int i;
> +GString *s = g_string_new(NULL);
> +MachineClass *mc = MACHINE_GET_CLASS(machine);
> +const CPUArchIdList *possible_cpus = mc->possible_cpu_arch_ids(machine);
> +
> +assert(nb_numa_nodes);
> +for (i = 0; i < possible_cpus->len; i++) {
> +const CPUArchId *cpu_slot = &possible_cpus->cpus[i];
> +
> +/* at this point numa mappings are initilized by CLI options
> + * or with default mappings so it's sufficient to list
> + * all not yet mapped CPUs here */
> +/* TODO: make it hard error in future */
> +if (!cpu_slot->props.has_node_id) {
> +char *cpu_str = cpu_slot_to_string(cpu_slot);
> +g_string_append_printf(s, "%sCPU %d [%s]", s->len ? ", " : "", i,
> +   cpu_str);
> +g_free(cpu_str);
> +}
> +}
> +if (s->len) {
> +error_report("warning: CPU(s) not present in any NUMA nodes: %s",
> + s->str);
> +error_report("warning: All CPU(s) up to maxcpus should be described "
> + "in NUMA config, ability to start up with partial NUMA "
> + "mappings is obsoleted and will be removed in future");

I can see this gripes in output of make check.  Shouldn't you suppress
them on qtest_enabled(), like we do elsewhere?

> +}
> +g_string_free(s, true);
> +}

[...]

Re: [Qemu-devel] [Bug 1691379] [NEW] NetBSD evbmips64el port installation doesn't work with qemu-system-mips64el.

[Thomas Huth]

On 17.05.2017 09:52, Utkarsh Anand wrote:
> Public bug reported:
> 
> I successfully installed the NetBSD evbmips64el port on gxemul but was
> unable to install it on qemu. Trying to boot it on qemu takes me to the
> 'db>' prompt. Here's the output and backtrace:
> 
> panic: pcib_isa_intr_string: bogus isa irq 0x0
> kernel: breakpoint trap
> Stopped in pid 0.1 (system) at  netbsd:cpu_Debugger+0x4:jr  ra
> bdslot: nop
> db> bt
> 0x805977f0: cpu_Debugger+4 
> (63061,9000180003f8,6,804c2290) ra 8030acd0 sz 0
> 0x805977f0: vpanic+158 (63061,9000180003f8,6,804c2290) ra 
> 8030ad7c sz 64
> 0x80597830: panic+34 (63061,803d65b0,0,40) ra 
> 80109784 sz 96
> 0x80597890: pcib_isa_intr_string+6c (63061,803d65b0,0,40) ra 
> 80149bfc sz 16
> 0x805978a0: uhci_pci_attach+16c (63061,803d65b0,0,40) ra 
> 802f0400 sz 176
> 0x80597950: config_attach_loc+1c8 (63061,803d65b0,0,40) ra 
> 802f053c sz 64
> 0x80597990: config_found_sm_loc+5c (63061,803d65b0,0,40) ra 
> 80121354 sz 64
> 0x805979d0: pci_probe_device+524 (63061,803d65b0,0,0) ra 
> 80121548 sz 288
> 0x80597af0: pci_enumerate_bus+1d0 (63061,803d65b0,0,0) ra 
> 8012167c sz 160
> 0x80597b90: pcirescan+5c (63061,803d65b0,0,0) ra 
> 801218c4 sz 32
> 0x80597bb0: pciattach+19c (63061,803d65b0,0,0) ra 
> 802f0400 sz 80
> 0x80597c00: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
> 802f053c sz 64
> 0x80597c40: config_found_sm_loc+5c (63061,803d65b0,0,0) ra 
> 80108934 sz 64
> 0x80597c80: gt_attach+7c (63061,803d65b0,0,0) ra 
> 802f0400 sz 112   
> 0x80597cf0: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
> 802f053c sz 64
> 0x80597d30: config_found_sm_loc+5c (63061,803d65b0,0,0) ra 
> 801086ac sz 64
> 0x80597d70: mainbus_attach+dc (63061,803d65b0,0,0) ra 
> 802f0400 sz 96
> 0x80597dd0: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
> 80104bf8 sz 64
> 0x80597e10: cpu_configure+28 (63061,803d65b0,0,0) ra 
> 803d5f30 sz 16
> 0x80597e20: main+3a0 (63061,803d65b0,0,0) ra 801000dc 
> sz 128   
> 0x80597ea0: kernel_text+dc (63061,803d65b0,0,0) ra 0 sz 0
> User-level: pid 0.1
> 
> Here's the command that I used:
> 
> Build evbmips64el from source and then launch it from qemu (replace the
> paths relative to your system):
> 
> qemu-system-mips64el -cdrom
> /extra/evbmips64/distrib/evbmips/cdroms/installcd/NetBSD-7.99.71
> -evbmips-mips64el.iso -hda /extra/evbmips64.img -kernel
> /extra/evbmips64/releasedir/evbmips/installation/netbsd-INSTALL_MALTA64
> -nographic -M malta
> 
> (I've decompressed the kernel)
> 
> Here's the output for qemu-system-mips64el --version :
> 
> QEMU emulator version 2.7.1(qemu-2.7.1-6.fc25), Copyright (c) 2003-2016
> Fabrice Bellard and the QEMU Project developers
> 
> This doesn't look like a NetBSD bug. I've attached a screenshot of the
> working installation using gxemul in the attachments.

When reporting such issues, please always use the latest release of QEMU
first, so could you please try again with the latest upstream release of
QEMU (currently v2.9.0)? Thanks!

 Thomas

[Qemu-devel] [PATCH] ui: egl-headless requires dmabuf support

[Gerd Hoffmann]

Reported-by: Thomas Huth 
Signed-off-by: Gerd Hoffmann 
---
 ui/Makefile.objs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index aac6ae8bef..3369451285 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -33,7 +33,7 @@ common-obj-y += shader.o
 common-obj-y += console-gl.o
 common-obj-y += egl-helpers.o
 common-obj-y += egl-context.o
-common-obj-y += egl-headless.o
+common-obj-$(CONFIG_OPENGL_DMABUF) += egl-headless.o
 ifeq ($(CONFIG_GTK_GL),y)
 common-obj-$(CONFIG_GTK) += gtk-gl-area.o
 else
-- 
2.9.3

[Qemu-devel] [RESEND PATCH] virtio: allow broken device to notify guest

[Greg Kurz]

According to section 2.1.2 of the virtio-1 specification:

"The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state that
a reset is needed. If DRIVER_OK is set, after it sets DEVICE_NEEDS_RESET,
the device MUST send a device configuration change notification to the
driver."

Commit "f5ed36635d8f virtio: stop virtqueue processing if device is broken"
introduced a virtio_error() call that just does that:

- internally mark the device as broken
- set the DEVICE_NEEDS_RESET bit in the status
- send a configuration change notification

Unfortunately, virtio_notify_vector(), called by virtio_notify_config(),
returns right away when the device is marked as broken and the notification
isn't sent in this case.

The spec doesn't say whether a broken device can send notifications
in other situations or not. But since the driver isn't supposed to do
anything but to reset the device, it makes sense to keep the check in
virtio_notify_config().

Marking the device as broken AFTER the configuration change notification was
sent is enough to fix the issue.

Signed-off-by: Greg Kurz 
Reviewed-by: Cornelia Huck 
---
 hw/virtio/virtio.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Re-sending this patch with Cornelia's Reviewed-by and Cc'ing qemu-stable
since this is a spec violation, as suggested in:

Message-ID: <20170427183237-mutt-send-email-...@kernel.org>

Cheers,

--
Greg

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 03592c542a55..890b4d7eb751 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2451,12 +2451,12 @@ void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice 
*vdev, const char *fmt, ...)
 error_vreport(fmt, ap);
 va_end(ap);
 
-vdev->broken = true;
-
 if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
 virtio_set_status(vdev, vdev->status | VIRTIO_CONFIG_S_NEEDS_RESET);
 virtio_notify_config(vdev);
 }
+
+vdev->broken = true;
 }
 
 static void virtio_memory_listener_commit(MemoryListener *listener)

Re: [Qemu-devel] [PATCH] target/i386: enable A20 automatically in system management mode

[Paolo Bonzini]

On 16/05/2017 23:42, Kevin O'Connor wrote:
> 
> As for adding a new SeaBIOS build option to compile out support for
> A20 - that seems like a very small optimization that would risk memory
> corruption and hard to diagnose crashes.  SeaBIOS runs natively on
> real hardware (with coreboot and as a CSM on UEFI) as well as on
> QEMU/KVM.

Haswell (2013) no longer has A20 support (and hypervisors never had it,
not just KVM).

Thanks,

Paolo

Re: [Qemu-devel] [PATCH] ui: egl-headless requires dmabuf support

[no-reply]

Hi,

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

Subject: [Qemu-devel] [PATCH] ui: egl-headless requires dmabuf support
Type: series
Message-id: 20170517081332.25811-1-kra...@redhat.com

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/1494851980-6831-1-git-send-email-kw...@redhat.com 
-> patchew/1494851980-6831-1-git-send-email-kw...@redhat.com
 * [new tag] patchew/20170517081332.25811-1-kra...@redhat.com -> 
patchew/20170517081332.25811-1-kra...@redhat.com
Switched to a new branch 'test'
a3b9ecf ui: egl-headless requires dmabuf support

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

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

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

Re: [Qemu-devel] About QEMU BQL and dirty log switch in Migration

[Wanpeng Li]

2017-05-17 15:43 GMT+08:00 Paolo Bonzini :
>> Recently, I have tested the performance before migration and after migration 
>> failure
>> using spec cpu2006 https://www.spec.org/cpu2006/, which is a standard 
>> performance
>> evaluation tool.
>>
>> These are the steps:
>> ==
>>  (1) the version of kmod is 4.4.11(with slightly modified) and the version of
>>  qemu is 2.6.0
>> (with slightly modified), the kmod is applied with the following patch
>>
>> diff --git a/source/x86/x86.c b/source/x86/x86.c
>> index 054a7d3..75a4bb3 100644
>> --- a/source/x86/x86.c
>> +++ b/source/x86/x86.c
>> @@ -8550,8 +8550,10 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
>>  */
>> if ((change != KVM_MR_DELETE) &&
>> (old->flags & KVM_MEM_LOG_DIRTY_PAGES) &&
>> -   !(new->flags & KVM_MEM_LOG_DIRTY_PAGES))
>> -   kvm_mmu_zap_collapsible_sptes(kvm, new);
>> +   !(new->flags & KVM_MEM_LOG_DIRTY_PAGES)) {
>> +   printk(KERN_ERR "zj make KVM_REQ_MMU_RELOAD request\n");
>> +   kvm_make_all_cpus_request(kvm, KVM_REQ_MMU_RELOAD);
>> +   }
>>
>> /*
>>  * Set up write protection and/or dirty logging for the new slot.
>
> Try these modifications to the setup:
>
> 1) set up 1G hugetlbfs hugepages and use those for the guest's memory
>
> 2) test both without and with the above patch.
>

In addition, we can compare /sys/kernel/debug/kvm/largepages w/ and
w/o the patch. IIRC, /sys/kernel/debug/kvm/largepages will drop during
live migration, it will keep a small value if live migration fails and
w/o "lazy collapse small sptes into large sptes" codes, however, it
will increase gradually if w/ the "lazy collapse small sptes into
large sptes" codes.

Regards,
Wanpeng Li

Re: [Qemu-devel] [PATCH 0/4] exec: address space translation cleanups

[Peter Xu]

On Wed, May 17, 2017 at 09:26:25AM +0200, Paolo Bonzini wrote:
> 
> 
> On 17/05/2017 09:17, Maxime Coquelin wrote:
> > 
> > 
> > On 05/17/2017 07:57 AM, Peter Xu wrote:
> >> On Wed, May 17, 2017 at 12:23:42PM +0800, Peter Xu wrote:
> >>> On Tue, May 16, 2017 at 06:51:03PM +0200, Maxime Coquelin wrote:
>  Hi Peter,
> 
>  On 05/16/2017 03:24 PM, Maxime Coquelin wrote:
> >
> >
> > On 05/15/2017 10:50 AM, Peter Xu wrote:
> >> The problem is that, address_space_get_iotlb_entry() shares a lot
> >> with
> >> address_space_translate(). This patch tries to abstract the
> >> shared elements.
> >>
> >> Originally, this work is derived from discussion from VT-d
> >> passthrough
> >> series discussions [1]. But for sure we can just see this series as a
> >> standalone cleanup. So I posted it separately here.
> >>
> >> Smoke tests are done with general VM boots, IOs, especially with
> >> vhost
> >> dmar configurations.
> >>
> >> I believe with current series I can throw away the old patch [1],
> >> which may be good. But before that, please kindly review. Thanks.
> >
> > I faced the problem the old patch fixes when declaring and
> > attaching an
> > IOMMU device, but booting the kernel with intel_iommu=off.
> >
> > I tested again with patches 1 & 4 of your series, and I confirm it
> > fixes
> > the issue:
> > Tested-by: Maxime Coquelin 
> 
>  I did some more testing with my "vhost-user IOMMU" setup, and the
>  series
>  actually breaks with IOMMU device attached, and intel_iommu=on.
> 
>  The main difference with the previous passing test is the guest RAM
>  size. In the working setup, it is 2G of 2M hugepages, vs. 4G of 2M
>  hugepages in the failing one. Note that I also reproduce with
>  vhost-kernel
>  backend.
> 
>  The error happens in the first vhost_device_iotlb_miss() call:
>  qemu-system-x86_64: Fail to lookup the translated address b5d7c000
> 
>  I don't have the root cause yet, I'll keep you updated.
> >>>
> >>> Maxime,
> >>>
> >>> Thanks a lot for help testing this series!
> >>>
> >>> I reproduced this problem, and this is not a problem obvious enough
> >>> for me. Let me investigate as well.
> >>>
> >>> -- 
> >>> Peter Xu
> >>
> >> Maxime,
> >>
> >> Could you help try adding this change upon current to see whether
> >> problem solved?
> > 
> > Hi Peter,
> > 
> > Yes, problem is solved with below change.
> 
> Cool---Peter, please send the new patch 4 as toplevel message!

Will do. Thanks!

-- 
Peter Xu

[Qemu-devel] [Bug 1181796] Re: Qemu locks up when incoming serial fills up

[Thomas Huth]

I think there have been quite a lot of fixes during the last releases of
QEMU in this area ... could you please try again to see whether you can
still reproduce this problem with the latest version of QEMU (currently
v2.9.0)?

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

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

Title:
  Qemu locks up when incoming serial fills up

Status in QEMU:
  Incomplete

Bug description:
  I'm using Windows, I'm not sure if this happens on Linux, but for all
  I know it does. To repro, fire up any image (ideally one that does
  almost nothing, and doesn't read the serial port), and use the option
  "-serial pipe:mypipe". Then use Putty or something else to connect to
  that named pipe so Qemu starts up. Now start typing into Putty. For a
  VM image that never reads the serial port, upon typing the 16th
  character Qemu stops executing instructions in the guest (as evidenced
  either by being unable to step in gdb, seeing that "info registers" in
  the monitor always reports the same value, or just by observing that
  the guest is hung). For OS images that do regularly read the serial
  port, this may require pasting >16 bytes into Putty at once. This
  occurs with more than just Putty, use anything that can write at a
  named pipe.

  I would have expected that bytes get dropped, or even more ideally
  blocked at the sender's side of the named pipe. I would not expect
  that the entire VM stops. You seem to be able to unwedge the VM by
  switching to the monitor and running "i /1c 0x3f8" until you've pulled
  enough out of buffer that it's happy to run again. Interestingly, all
  bytes seem to come through (more than just the 16) when read from the
  monitor.

  I haven't been able to get a source environment set up, but I have
  tried a few of the Windows binaries. This repros in 1.4.1, 1.3.0, 1.2,
  and 1.0, the most recent build I found that did not have this behavior
  was 0.15.0.

  Maybe I'm missing something very obvious, and if so, I apologize in
  advance. I'm also happy to create an OS image that highlights this
  problem if it would help.

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

Re: [Qemu-devel] [RFC v1 5/9] virtio-crypto: update header file

[Gonglei (Arei)]

>
> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Tuesday, May 16, 2017 11:43 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; m...@redhat.com; Huangweidong (C);
> pa...@linux.vnet.ibm.com; Luonengjun; cornelia.h...@de.ibm.com;
> Linqiangmin; xin.z...@intel.com; Wubin (H)
> Subject: Re: [RFC v1 5/9] virtio-crypto: update header file
> 
> On Mon, May 08, 2017 at 07:38:20PM +0800, Gonglei wrote:
> > @@ -166,8 +175,8 @@ struct virtio_crypto_aead_session_para {
> > uint32_t algo;
> > /* length of key */
> > uint32_t key_len;
> > -   /* hash result length */
> > -   uint32_t hash_result_len;
> > +   /* Authentication tag length */
> > +   uint32_t tag_len;
> 
> Why is this field being renamed?

Oh, I just think the latter name ' tag_len' is more proper than 
'hash_result_len',
and the current code don't touch this field.

Thanks,
-Gonglei

Re: [Qemu-devel] [PATCH 11/17] object: use more specific property type names

[Markus Armbruster]

Marc-André Lureau  writes:

> Use the actual unsigned integer type name (this should't break since
> property type aren't directly accessed from outside it seems).

I'm not sure I understand the parenthesis.  Do you mean changing the
type names is safe because they're used only in a certain way?  Which
way?

How did you find the names that need fixing?

> Signed-off-by: Marc-André Lureau 
> ---
>  backends/cryptodev.c |  2 +-
>  hw/pci-host/piix.c   |  8 
>  hw/pci-host/q35.c| 10 +-
>  hw/ppc/pnv.c |  2 +-
>  net/dump.c   |  2 +-
>  net/filter-buffer.c  |  2 +-
>  6 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/backends/cryptodev.c b/backends/cryptodev.c
> index 832f056266..1764c179fe 100644
> --- a/backends/cryptodev.c
> +++ b/backends/cryptodev.c
> @@ -222,7 +222,7 @@ cryptodev_backend_can_be_deleted(UserCreatable *uc, Error 
> **errp)
>  
>  static void cryptodev_backend_instance_init(Object *obj)
>  {
> -object_property_add(obj, "queues", "int",
> +object_property_add(obj, "queues", "uint32",
>cryptodev_backend_get_queues,
>cryptodev_backend_set_queues,
>NULL, NULL, NULL);

Correct, because the callbacks access struct CryptoDevBackendPeers
member queues, which is uint32_t.

The callbacks pass a local variable instead of the struct member to the
visitor.  Problematic, because it weakens the type checking we get from
the compiler.  Let's tighten it up:

   static void
   cryptodev_backend_get_queues(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
   {
   CryptoDevBackend *backend = CRYPTODEV_BACKEND(obj);
  -uint32_t value = backend->conf.peers.queues;

  -visit_type_uint32(v, name, &value, errp);
  +visit_type_uint32(v, name, &backend->conf.peers.queues, errp);
   }

   static void
   cryptodev_backend_set_queues(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
   {
   CryptoDevBackend *backend = CRYPTODEV_BACKEND(obj);
   Error *local_err = NULL;
  -uint32_t value;

  -visit_type_uint32(v, name, &value, &local_err);
  +visit_type_uint32(v, name, &backend->conf.peers.queues, &local_err);
   if (local_err) {
   goto out;
   }
  -if (!value) {
  +if (!backend->conf.peers.queues) {
   error_setg(&local_err, "Property '%s.%s' doesn't take value '%"
  -   PRIu32 "'", object_get_typename(obj), name, value);
  +   PRIu32 "'", object_get_typename(obj), name,
  +   backend->conf.peers.queues);
  -goto out;
   }
  -backend->conf.peers.queues = value;
  -out:
   error_propagate(errp, local_err);
   }

If we need to preserve backend->conf.peers.queue on an attempt to set it
to zero, things get a bit more complicated.  But having the compiler
enforce the visitor matches the member type exactly is worth it, in my
opinion.

Separate patch, not necessarily in this series.

> diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
> index f9218aa952..9aed6225bf 100644
> --- a/hw/pci-host/piix.c
> +++ b/hw/pci-host/piix.c
> @@ -279,19 +279,19 @@ static void i440fx_pcihost_initfn(Object *obj)
>  memory_region_init_io(&s->data_mem, obj, &pci_host_data_le_ops, s,
>"pci-conf-data", 4);
>  
> -object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "int",
> +object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "uint32",
>  i440fx_pcihost_get_pci_hole_start,
>  NULL, NULL, NULL, NULL);
>  
> -object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_END, "int",
> +object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_END, "uint32",
>  i440fx_pcihost_get_pci_hole_end,
>  NULL, NULL, NULL, NULL);
>  
> -object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_START, "int",
> +object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_START, "uint64",
>  i440fx_pcihost_get_pci_hole64_start,
>  NULL, NULL, NULL, NULL);
>  
> -object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_END, "int",
> +object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_END, "uint64",
>  i440fx_pcihost_get_pci_hole64_end,
>  NULL, NULL, NULL, NULL);
>  }

These look good.  The underlying values are 64 bits, but the 32 bit
callbacks assert they fit into 32.

> diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> index 344f77b10c..5438be8253 100644
> --- a/hw/pci-host/q35.c
> +++ b/hw/pci-host/q35.c
> @@ -176,23 +176,23 @@ static void q35_host_initfn(Object *obj)
>  qdev_prop_set_uint32(DEVICE(&s->mch), "addr", PCI_DEVFN(0, 0));
>  qdev_prop_set_bit(DEVICE(&s->mch), "multifunction", false);
>  
> -object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_STAR

Re: [Qemu-devel] [RFC 0/2] pseries: Correct behaviour change for older machine types

[Andrea Bolognani]

On Wed, 2017-05-17 at 16:35 +1000, David Gibson wrote:
> 152ef80 "pseries: Rewrite CAS PVR compatibility logic" incorrectly
> introduced a guest-visible behaviour change into existing versioned
> machine type.  Patch 2/2 corrects this change, while 1/2 is a
> preliminary clean up to make that easier.
> 
> Unfortunately, this bug is already in the released qemu-2.9.0.  Once
> this is ready to merge for master, I'll make a backport to apply for
> 2.9.1 as well.
> 
> David Gibson (2):
>   pseries: Split CAS PVR negotiation out into a separate function
>   pseries: Restore PVR negotiation logic for pre-2.9 machine types
> 
>  hw/ppc/spapr.c |   3 ++
>  hw/ppc/spapr_hcall.c   | 131 
>+++--
>  include/hw/ppc/spapr.h |   1 +
>  3 files changed, 119 insertions(+), 16 deletions(-)

I gave it a spin and I can no longer reproduce the issue,
so for the entire series:

Tested-by: Andrea Bolognani 

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [RFC 1/2] pseries: Split CAS PVR negotiation out into a separate function

[Laurent Vivier]

On 17/05/2017 08:35, David Gibson wrote:
> Guests of the qemu machine type go through a feature negotiation process
> known as "client architecture support" (CAS) during early boot.  This does
> a number of things, one of which is finding a CPU compatibility mode which
> can be supported by both guest and host.
> 
> In fact the CPU negotiation is probably the single most complex part of the
> CAS process, so this splits it out into a helper function.  We've recently
> made some mistakes in maintaining backward compatibility for old machine
> types here.  Splitting this out will also make it easier to fix this.
> 
> This also adds a possibly useful error message if the negotiation fails
> (i.e. if there is CPU mode that's suitable for both guest and host).
> 
> Signed-off-by: David Gibson 
> ---
>  hw/ppc/spapr_hcall.c | 43 +++
>  1 file changed, 27 insertions(+), 16 deletions(-)
> 
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 0d608d6..007ae8d 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1047,19 +1047,13 @@ static target_ulong h_signal_sys_reset(PowerPCCPU 
> *cpu,
>  }
>  }
>  
> -static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
> -  sPAPRMachineState *spapr,
> -  target_ulong opcode,
> -  target_ulong *args)
> +static uint32_t cas_check_pvr(PowerPCCPU *cpu, target_ulong list,
> +  Error **errp)
>  {
> -target_ulong list = ppc64_phys_to_real(args[0]);
> -target_ulong ov_table;
>  bool explicit_match = false; /* Matched the CPU's real PVR */
>  uint32_t max_compat = cpu->max_compat;
>  uint32_t best_compat = 0;
>  int i;
> -sPAPROptionVector *ov1_guest, *ov5_guest, *ov5_cas_old, *ov5_updates;
> -bool guest_radix;
>  
>  /*
>   * We scan the supplied table of PVRs looking for two things
> @@ -1090,26 +1084,43 @@ static target_ulong 
> h_client_architecture_support(PowerPCCPU *cpu,
>  /* We couldn't find a suitable compatibility mode, and either
>   * the guest doesn't support "raw" mode for this CPU, or raw
>   * mode is disabled because a maximum compat mode is set */
> -return H_HARDWARE;
> +error_setg(errp, "Couldn't negotiate a suitable PVR during CAS");
> +return 0;
>  }
>  
>  /* Parsing finished */
>  trace_spapr_cas_pvr(cpu->compat_pvr, explicit_match, best_compat);
>  
> -/* Update CPUs */
> -if (cpu->compat_pvr != best_compat) {
> -Error *local_err = NULL;
> +return best_compat;
> +}
> +
> +static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
> +  sPAPRMachineState *spapr,
> +  target_ulong opcode,
> +  target_ulong *args)
> +{
> +/* @ov_table points to the first option vector */
> +target_ulong ov_table = ppc64_phys_to_real(args[0]);
> +uint32_t cas_pvr;
> +sPAPROptionVector *ov1_guest, *ov5_guest, *ov5_cas_old, *ov5_updates;
> +bool guest_radix;
> +Error *local_err = NULL;
>  
> -ppc_set_compat_all(best_compat, &local_err);
> +cas_pvr = cas_check_pvr(cpu, ov_table, &local_err);
> +if (local_err) {
> +error_report_err(local_err);
> +return H_HARDWARE;
> +}
> +
> +/* Update CPUs */
> +if (cpu->compat_pvr != cas_pvr) {
> +ppc_set_compat_all(cas_pvr, &local_err);
>  if (local_err) {
>  error_report_err(local_err);
>  return H_HARDWARE;
>  }
>  }
>  
> -/* For the future use: here @ov_table points to the first option vector 
> */
> -ov_table = list;
> -

I think there is a change here: now ov_table is always
ppc64_phys_to_real(args[0]), as it is not updated by cas_check() as list
was by h_client_architecture_support().

>  ov1_guest = spapr_ovec_parse_vector(ov_table, 1);
>  ov5_guest = spapr_ovec_parse_vector(ov_table, 5);
>  if (spapr_ovec_test(ov5_guest, OV5_MMU_BOTH)) {

Laurent

[Qemu-devel] [PATCH v2] exec: abstract address_space_do_translate()

[Peter Xu]

This function is an abstraction helper for address_space_translate() and
address_space_get_iotlb_entry(). It does the lookup of address into
memory region section, then do proper IOMMU translation if necessary.
With that, refactor the two existing functions a bit to use it.

This fixes a potential vhost dmar issue when with IOMMU passthrough
mode.

Tested-by: Maxime Coquelin 
Signed-off-by: Peter Xu 
---
v2:
- added the lines to fix issue reported by Maxime [Maxime]
- considering that what Maxime tested is exactly this patch after
  applying the change, add t-b line for Maxime
---
 exec.c | 103 +++--
 1 file changed, 69 insertions(+), 34 deletions(-)

diff --git a/exec.c b/exec.c
index eac6085..f942eb2 100644
--- a/exec.c
+++ b/exec.c
@@ -463,18 +463,20 @@ address_space_translate_internal(AddressSpaceDispatch *d, 
hwaddr addr, hwaddr *x
 }
 
 /* Called from RCU critical section */
-IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
-bool is_write)
+static MemoryRegionSection address_space_do_translate(AddressSpace *as,
+  hwaddr addr,
+  hwaddr *xlat,
+  hwaddr *plen,
+  bool is_write,
+  bool is_mmio)
 {
-IOMMUTLBEntry iotlb = {0};
+IOMMUTLBEntry iotlb;
 MemoryRegionSection *section;
 MemoryRegion *mr;
 
 for (;;) {
 AddressSpaceDispatch *d = atomic_rcu_read(&as->dispatch);
-section = address_space_lookup_region(d, addr, false);
-addr = addr - section->offset_within_address_space
-   + section->offset_within_region;
+section = address_space_translate_internal(d, addr, &addr, plen, 
is_mmio);
 mr = section->mr;
 
 if (!mr->iommu_ops) {
@@ -482,55 +484,88 @@ IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace 
*as, hwaddr addr,
 }
 
 iotlb = mr->iommu_ops->translate(mr, addr, is_write);
+addr = ((iotlb.translated_addr & ~iotlb.addr_mask)
+| (addr & iotlb.addr_mask));
+*plen = MIN(*plen, (addr | iotlb.addr_mask) - addr + 1);
 if (!(iotlb.perm & (1 << is_write))) {
-iotlb.target_as = NULL;
-break;
+goto translate_fail;
 }
 
-addr = ((iotlb.translated_addr & ~iotlb.addr_mask)
-| (addr & iotlb.addr_mask));
 as = iotlb.target_as;
 }
 
-return iotlb;
+*xlat = addr;
+
+return *section;
+
+translate_fail:
+return (MemoryRegionSection) { .mr = &io_mem_unassigned };
 }
 
 /* Called from RCU critical section */
-MemoryRegion *address_space_translate(AddressSpace *as, hwaddr addr,
-  hwaddr *xlat, hwaddr *plen,
-  bool is_write)
+IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
+bool is_write)
 {
-IOMMUTLBEntry iotlb;
-MemoryRegionSection *section;
-MemoryRegion *mr;
+MemoryRegionSection section;
+hwaddr xlat, plen;
 
-for (;;) {
-AddressSpaceDispatch *d = atomic_rcu_read(&as->dispatch);
-section = address_space_translate_internal(d, addr, &addr, plen, true);
-mr = section->mr;
+/* Try to get maximum page mask during translation. */
+plen = (hwaddr)-1;
 
-if (!mr->iommu_ops) {
-break;
-}
+/* This can never be MMIO. */
+section = address_space_do_translate(as, addr, &xlat, &plen,
+ is_write, false);
 
-iotlb = mr->iommu_ops->translate(mr, addr, is_write);
-addr = ((iotlb.translated_addr & ~iotlb.addr_mask)
-| (addr & iotlb.addr_mask));
-*plen = MIN(*plen, (addr | iotlb.addr_mask) - addr + 1);
-if (!(iotlb.perm & (1 << is_write))) {
-mr = &io_mem_unassigned;
-break;
-}
+/* Illegal translation */
+if (section.mr == &io_mem_unassigned) {
+goto iotlb_fail;
+}
 
-as = iotlb.target_as;
+/* Convert memory region offset into address space offset */
+xlat += section.offset_within_address_space -
+section.offset_within_region;
+
+if (plen == (hwaddr)-1) {
+/*
+ * We use default page size here. Logically it only happens
+ * for identity mappings.
+ */
+plen = TARGET_PAGE_SIZE;
 }
 
+/* Convert to address mask */
+plen -= 1;
+
+return (IOMMUTLBEntry) {
+.target_as = section.address_space,
+.iova = addr & ~plen,
+.translated_addr = xlat & ~plen,
+.addr_mask = plen,
+/* IOTLBs are for DMAs, and DMA only allows on RAMs. */
+.

Re: [Qemu-devel] [PULL 23/29] numa: use possible_cpus for not mapped CPUs check

[Igor Mammedov]

On Wed, 17 May 2017 10:07:18 +0200
Markus Armbruster  wrote:

> Eduardo Habkost  writes:
> 
> > From: Igor Mammedov 
> >
> > and remove corresponding part in numa.c that uses
> > node_cpu bitmaps.
> >
> > Signed-off-by: Igor Mammedov 
> > Reviewed-by: David Gibson 
> > Reviewed-by: Andrew Jones 
> > Message-Id: <1494415802-227633-16-git-send-email-imamm...@redhat.com>
> > Signed-off-by: Eduardo Habkost 
> > ---
> >  hw/core/machine.c | 58 
> > +++
> >  numa.c| 10 --
> >  2 files changed, 58 insertions(+), 10 deletions(-)
> >
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index 64e2a4ff2c..fd6a436064 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -20,6 +20,7 @@
> >  #include "sysemu/numa.h"
> >  #include "qemu/error-report.h"
> >  #include "qemu/cutils.h"
> > +#include "sysemu/numa.h"
> >  
> >  static char *machine_get_accel(Object *obj, Error **errp)
> >  {
> > @@ -678,9 +679,66 @@ bool machine_mem_merge(MachineState *machine)
> >  return machine->mem_merge;
> >  }
> >  
> > +static char *cpu_slot_to_string(const CPUArchId *cpu)
> > +{
> > +GString *s = g_string_new(NULL);
> > +if (cpu->props.has_socket_id) {
> > +g_string_append_printf(s, "socket-id: %"PRId64, 
> > cpu->props.socket_id);
> > +}
> > +if (cpu->props.has_core_id) {
> > +if (s->len) {
> > +g_string_append_printf(s, ", ");
> > +}
> > +g_string_append_printf(s, "core-id: %"PRId64, cpu->props.core_id);
> > +}
> > +if (cpu->props.has_thread_id) {
> > +if (s->len) {
> > +g_string_append_printf(s, ", ");
> > +}
> > +g_string_append_printf(s, "thread-id: %"PRId64, 
> > cpu->props.thread_id);
> > +}
> > +return g_string_free(s, false);
> > +}
> > +
> > +static void machine_numa_validate(MachineState *machine)
> > +{
> > +int i;
> > +GString *s = g_string_new(NULL);
> > +MachineClass *mc = MACHINE_GET_CLASS(machine);
> > +const CPUArchIdList *possible_cpus = 
> > mc->possible_cpu_arch_ids(machine);
> > +
> > +assert(nb_numa_nodes);
> > +for (i = 0; i < possible_cpus->len; i++) {
> > +const CPUArchId *cpu_slot = &possible_cpus->cpus[i];
> > +
> > +/* at this point numa mappings are initilized by CLI options
> > + * or with default mappings so it's sufficient to list
> > + * all not yet mapped CPUs here */
> > +/* TODO: make it hard error in future */
> > +if (!cpu_slot->props.has_node_id) {
> > +char *cpu_str = cpu_slot_to_string(cpu_slot);
> > +g_string_append_printf(s, "%sCPU %d [%s]", s->len ? ", " : "", 
> > i,
> > +   cpu_str);
> > +g_free(cpu_str);
> > +}
> > +}
> > +if (s->len) {
> > +error_report("warning: CPU(s) not present in any NUMA nodes: %s",
> > + s->str);
> > +error_report("warning: All CPU(s) up to maxcpus should be 
> > described "
> > + "in NUMA config, ability to start up with partial 
> > NUMA "
> > + "mappings is obsoleted and will be removed in 
> > future");  
> 
> I can see this gripes in output of make check.  Shouldn't you suppress
> them on qtest_enabled(), like we do elsewhere?
I'll look into it and add a patch into followup series to suppress it.

> 
> > +}
> > +g_string_free(s, true);
> > +}  
> 
> [...]

Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request

[Gonglei (Arei)]

> From: Halil Pasic [mailto:pa...@linux.vnet.ibm.com]
> Sent: Wednesday, May 17, 2017 6:18 AM
> 
> 
> On 05/16/2017 04:52 AM, Gonglei (Arei) wrote:
> >>
> >> On 05/13/2017 03:16 AM, Gonglei (Arei) wrote:
> >>>
>  From: Halil Pasic [mailto:pa...@linux.vnet.ibm.com]
>  Sent: Friday, May 12, 2017 7:02 PM
> 
> 
>  On 05/08/2017 01:38 PM, Gonglei wrote:
> > According to the new spec, we should use different
> > requst structure to store the data request based
> > on whether VIRTIO_CRYPTO_F_MUX_MODE feature bit is
> > negotiated or not.
> >
> > In this patch, we havn't supported stateless mode
> > yet. The device reportes an error if both
> > VIRTIO_CRYPTO_F_MUX_MODE and
>  VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE
> > are negotiated, meanwhile the header.flag doesn't set
> > to VIRTIO_CRYPTO_FLAG_SESSION_MODE.
> >
> > Let's handle this scenario in the following patches.
> >
> > Signed-off-by: Gonglei 
> > ---
> >  hw/virtio/virtio-crypto.c | 83
>  ---
> >  1 file changed, 71 insertions(+), 12 deletions(-)
> >
> > diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
> > index 0353eb6..c4b8a2c 100644
> > --- a/hw/virtio/virtio-crypto.c
> > +++ b/hw/virtio/virtio-crypto.c
> > @@ -577,6 +577,7 @@ virtio_crypto_handle_request(VirtIOCryptoReq
>  *request)
> >  VirtQueueElement *elem = &request->elem;
> >  int queue_index =
>  virtio_crypto_vq2q(virtio_get_queue_index(request->vq));
> >  struct virtio_crypto_op_data_req req;
> > +struct virtio_crypto_op_data_req_mux req_mux;
> >  int ret;
> >  struct iovec *in_iov;
> >  struct iovec *out_iov;
> > @@ -587,6 +588,9 @@ virtio_crypto_handle_request(VirtIOCryptoReq
>  *request)
> >  uint64_t session_id;
> >  CryptoDevBackendSymOpInfo *sym_op_info = NULL;
> >  Error *local_err = NULL;
> > +bool mux_mode_is_negotiated;
> > +struct virtio_crypto_op_header *header;
> > +bool is_stateless_req = false;
> >
> >  if (elem->out_num < 1 || elem->in_num < 1) {
> >  virtio_error(vdev, "virtio-crypto dataq missing headers");
> > @@ -597,12 +601,28 @@
> virtio_crypto_handle_request(VirtIOCryptoReq
>  *request)
> >  out_iov = elem->out_sg;
> >  in_num = elem->in_num;
> >  in_iov = elem->in_sg;
> > -if (unlikely(iov_to_buf(out_iov, out_num, 0, &req, sizeof(req))
> > -!= sizeof(req))) {
> > -virtio_error(vdev, "virtio-crypto request outhdr too short");
> > -return -1;
> > +
> > +mux_mode_is_negotiated =
> > +virtio_vdev_has_feature(vdev,
> >> VIRTIO_CRYPTO_F_MUX_MODE);
> > +if (!mux_mode_is_negotiated) {
> > +if (unlikely(iov_to_buf(out_iov, out_num, 0, &req, sizeof(req))
> > +!= sizeof(req))) {
> > +virtio_error(vdev, "virtio-crypto request outhdr too
> short");
> > +return -1;
> > +}
> > +iov_discard_front(&out_iov, &out_num, sizeof(req));
> > +
> > +header = &req.header;
> > +} else {
> > +if (unlikely(iov_to_buf(out_iov, out_num, 0, &req_mux,
> > +sizeof(req_mux)) != sizeof(req_mux))) {
> > +virtio_error(vdev, "virtio-crypto request outhdr too
> short");
> > +return -1;
> > +}
> > +iov_discard_front(&out_iov, &out_num, sizeof(req_mux));
> > +
> > +header = &req_mux.header;
> 
>  I wonder if this request length checking logic is conform to the
>  most recent spec draft on the list ("[PATCH v18 0/2] virtio-crypto:
>  virtio crypto device specification").
> 
> >>> Sure. Please see below normative formulation:
> >>>
> >>> '''
> >>> \drivernormative{\paragraph}{Symmetric algorithms Operation}{Device
> Types
> >> / Crypto Device / Device Operation / Symmetric algorithms Operation}
> >>> ...
> >>> \item If the VIRTIO_CRYPTO_F_MUX_MODE feature bit is negotiated, the
> >> driver MUST use struct virtio_crypto_op_data_req_mux to wrap crypto
> >> requests.
> >>> Otherwise, the driver MUST use struct virtio_crypto_op_data_req.
> >>> ...
> >>> '''
> >>>
> >>
> >> As far as I can remember, we have already agreed that in terms of the
> >> spec sizeof(struct virtio_crypto_op_data_req) makes no sense! In your
> >
> > Sorry, I don't think so. :(
> >
> >> code you have a substantially different struct virtio_crypto_op_data_req
> >> than in your spec! For instance in the spec virtio_crypto_op_data_req is
> >> the full request and contains the data buffers (src_data and the
> >> dest_data), while in your code it's effectively just a header and does
> >> not contain any data buffers.
> >>
> > I said struct virtio_crypto_op_data_req in the spec is 

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

[Gonglei (Arei)]

>
> 
> On Sat, Apr 22, 2017 at 02:23:50PM +0800, Gonglei wrote:
> > +Dataq requests for both session and stateless modes are as follows:
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_op_data_req_mux {
> > +struct virtio_crypto_op_header header;
> > +
> > +union {
> > +struct virtio_crypto_sym_data_req   sym_req;
> > +struct virtio_crypto_hash_data_req  hash_req;
> > +struct virtio_crypto_mac_data_req   mac_req;
> > +struct virtio_crypto_aead_data_req  aead_req;
> > +struct virtio_crypto_sym_data_req_stateless
> sym_stateless_req;
> > +struct virtio_crypto_hash_data_req_stateless
> hash_stateless_req;
> > +struct virtio_crypto_mac_data_req_stateless
> mac_stateless_req;
> > +struct virtio_crypto_aead_data_req_stateless
> aead_stateless_req;
> > +} u;
> > +};
> > +\end{lstlisting}
> 
> Halil touched on this in the discussion: this spec uses a C-like struct
> syntax but does not define whether unions really affect sizeof(mystruct)
> like they would in C or whether you just mean that any of the union
> fields can be used.  This distinction is important so device and driver
> authors understand the exact memory layout of requests and responses.
> 
> Please include an explanation about the meaning of "union" in the text.
> 
Halil has different opinion in other thread, I replied.

I'll wait for his new response about it. Thanks!

> > +Session mode MAC service requests are as follows:
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_mac_para {
> > +struct virtio_crypto_hash_para hash;
> > +};
> > +
> > +struct virtio_crypto_mac_data_req {
> > +/* Device-readable part */
> > +struct virtio_crypto_mac_para para;
> > +/* Source data */
> > +u8 src_data[src_data_len];
> > +
> > +/* Device-writable part */
> > +/* Hash result data */
> > +u8 hash_result[hash_result_len];
> > +struct virtio_crypto_inhdr inhdr;
> > +};
> > +\end{lstlisting}
> > +
> > +Each data request uses virtio_crypto_mac_data_req structure to store
> information
> 
> "Each request uses the virtio_crypto_mac_data_req structure to store
> information"
> 
OK.

> > +Session mode requests of symmetric algorithm are as follows:
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_sym_data_req {
> > +union {
> > +struct virtio_crypto_cipher_data_req cipher;
> > +struct virtio_crypto_alg_chain_data_req chain;
> > +} u;
> > +
> > +/* Device-readable part */
> > +
> > +/* See above VIRTIO_CRYPTO_SYM_OP_* */
> > +le32 op_type;
> > +le32 padding;
> > +};
> > +\end{lstlisting}
> > +
> > +Each data request uses virtio_crypto_sym_data_req structure to store
> information
> 
> s/virtio_crypto_sym_data_req structure/the virtio_crypto_sym_data_req
> structure/

OK.

Thanks,
-Gonglei

Re: [Qemu-devel] [RFC 2/2] pseries: Restore PVR negotiation logic for pre-2.9 machine types

[Laurent Vivier]

On 17/05/2017 08:35, David Gibson wrote:
> "pseries" guests go through a hypervisor<->guest feature negotiation during
> early boot.  Part of this is finding a CPU compatibility mode which works
> for both.
> 
> In 152ef80 "pseries: Rewrite CAS PVR compatibility logic" this logic was
> changed to strongly prefer architecture defined CPU compatibility modes,
> rather than CPU "raw" modes.  However, this change was made universally,
> which introduces a guest visible change for the previously existing machine
> types (pseries-2.8 and earlier).  That's never supposed to happen.
> 
> This corrects the behaviour, reverting to the old PVR negotiation logic
> for machine types prior to pseries-2.9.
> 
> Fixes: 152ef803ceb1959e2380a1da7736b935b109222e
> Reported-by: Andrea Bolognani 
> Signed-off-by: David Gibson 
> ---
>  hw/ppc/spapr.c |  3 ++
>  hw/ppc/spapr_hcall.c   | 90 
> +-
>  include/hw/ppc/spapr.h |  1 +
>  3 files changed, 93 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index a9471b9..913355f 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -3308,9 +3308,12 @@ static void 
> spapr_machine_2_8_instance_options(MachineState *machine)
>  
>  static void spapr_machine_2_8_class_options(MachineClass *mc)
>  {
> +sPAPRMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
> +
>  spapr_machine_2_9_class_options(mc);
>  SET_MACHINE_COMPAT(mc, SPAPR_COMPAT_2_8);
>  mc->numa_mem_align_shift = 23;
> +smc->pre_2_9_cas_pvr = true;
>  }
>  
>  DEFINE_SPAPR_MACHINE(2_8, "2.8", false);
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 007ae8d..4937019 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1047,6 +1047,89 @@ static target_ulong h_signal_sys_reset(PowerPCCPU *cpu,
>  }
>  }
>  
> +/*
> + * Old logic for PVR negotiation, used old <2.9 machine types for
> + * compatibility with old qemu versions
> + */
> +#define get_compat_level(cpuver) (  \
> +((cpuver) == CPU_POWERPC_LOGICAL_2_05) ? 2050 : \
> +((cpuver) == CPU_POWERPC_LOGICAL_2_06) ? 2060 :  \
> +((cpuver) == CPU_POWERPC_LOGICAL_2_06_PLUS) ? 2061 :\
> +((cpuver) == CPU_POWERPC_LOGICAL_2_07) ? 2070 : 0)
> +
> +static void cas_handle_compat_cpu(PowerPCCPUClass *pcc, uint32_t pvr,
> +  unsigned max_lvl, unsigned *compat_lvl,
> +  unsigned *compat_pvr)
> +{
> +unsigned lvl = get_compat_level(pvr);
> +bool is205, is206, is207;
> +
> +if (!lvl) {
> +return;
> +}
> +
> +/* If it is a logical PVR, try to determine the highest level */
> +is205 = (pcc->pcr_supported & PCR_COMPAT_2_05) &&
> +(lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_05));
> +is206 = (pcc->pcr_supported & PCR_COMPAT_2_06) &&
> +((lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_06)) ||
> + (lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_06_PLUS)));
> +is207 = (pcc->pcr_supported & PCR_COMPAT_2_07) &&
> +(lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_07));
> +
> +if (is205 || is206 || is207) {
> +if (!max_lvl) {
> +/* User did not set the level, choose the highest */
> +if (*compat_lvl <= lvl) {
> +*compat_lvl = lvl;
> +*compat_pvr = pvr;
> +}
> +} else if (max_lvl >= lvl) {
> +/* User chose the level, don't set higher than this */
> +*compat_lvl = lvl;
> +*compat_pvr = pvr;
> +}
> +}
> +}
> +
> +static uint32_t cas_check_pvr_pre_2_9(PowerPCCPU *cpu, target_ulong list,
> +  Error **errp)
> +{
> +PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
> +int counter;
> +unsigned max_lvl = get_compat_level(cpu->max_compat);
> +bool cpu_match = false;
> +unsigned compat_lvl = 0, compat_pvr = 0;
> +
> +for (counter = 0; counter < 512; ++counter) {
> +uint32_t pvr, pvr_mask;
> +
> +pvr_mask = ldl_be_phys(&address_space_memory, list);
> +pvr = ldl_be_phys(&address_space_memory, list + 4);
> +list += 8;
> +
> +if (~pvr_mask & pvr) {
> +break; /* Terminator record */
> +}
> +
> +trace_spapr_cas_pvr_try(pvr);
> +if (!max_lvl &&
> +((cpu->env.spr[SPR_PVR] & pvr_mask) == (pvr & pvr_mask))) {
> +cpu_match = true;
> +compat_pvr = 0;
> +} else if (pvr == cpu->compat_pvr) {
> +cpu_match = true;
> +compat_pvr = cpu->compat_pvr;
> +} else if (!cpu_match) {
> +cas_handle_compat_cpu(pcc, pvr, max_lvl, &compat_lvl, 
> &compat_pvr);
> +}
> +}
> +
> +trace_spapr_cas_pvr(cpu->compat_pvr, cpu_match, compat_pvr);

Perhaps you can add a new function or a parameter to show which path
(pre_2_9 or not) we use to compute the CAS PVR

Re: [Qemu-devel] [PATCH] Memory: use memory address space for cpu-memory

[Igor Mammedov]

On Tue, 16 May 2017 15:15:23 -0700
Anthony Xu  wrote:

> If cpu-memory address space is same as memory address space,
> use memory address space for cpu-memory address space.
> 
> any memory region change causeaddress space to rebuild PhysPageMap,
> rebuilding PhysPageMap is very expensive.
> 
> removing cpu-memory address space reduces the guest boot time and
> memory usage.
> 
> Signed-off-by: Anthony Xu 
> ---
>  cpus.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/cpus.c b/cpus.c
> index 740b8dc..15c7a6a 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -1748,8 +1748,13 @@ void qemu_init_vcpu(CPUState *cpu)
>  /* If the target cpu hasn't set up any address spaces itself,
>   * give it the default one.
>   */
> -AddressSpace *as = address_space_init_shareable(cpu->memory,
> -"cpu-memory");
> +AddressSpace *as;
> +if (cpu->memory == address_space_memory.root) {
> +address_space_memory.ref_count++;
probably this would cause reference leak when vcpu is destroyed

> +as = &address_space_memory;
> +} else {
> +as = address_space_init_shareable(cpu->memory, "cpu-memory");
> +}
>  cpu->num_ases = 1;
>  cpu_address_space_init(cpu, as, 0);
>  }

Re: [Qemu-devel] [Qemu devel v5 PATCH 0/5] Add support for Smartfusion2 SoC

[sundeep subbaraya]

Hi Philippe,

On Wed, May 17, 2017 at 9:57 AM, Philippe Mathieu-Daudé 
wrote:

> Hi Sundeep,
>
> This patchset is way cleaner!
> I had a fast look and I like it, I'll try to make some time soon to review
> details and test it.


Thank you

>


> Is your work interested on U-Boot or more focused in Linux kernel?
>

I am interested more in kernel. I had to look into u-boot for first time
for Qemu only.
I worked only on FPGAs(load kernel with debugger) till now so never got a
chance to look into u-boot.

>
> If you compile QEMU with libfdt support you can use the -dtb option to
> pass the blob to the kernel directly, bypassing the bootloader.
>
> Yeah for armv7m I could not find any thing like that in tree.


> If you need a bootloader you may give a look at coreboot which supports
> dts well, see how Vladimir Serbinenko used Linux's dt to boot a QEMU
> Versatile Express board:
> https://mail.coreboot.org/pipermail/coreboot-gerrit/2016-
> February/040899.html
>
> Cool. I will look into it.

Thanks,
Sundeep


> Regards,
>
> Phil.
>
>
> On 05/16/2017 12:38 PM, Subbaraya Sundeep wrote:
>
>> Hi Qemu-devel,
>>
>> I am trying to add Smartfusion2 SoC.
>> SoC is from Microsemi and System on Module(SOM)
>> board is from Emcraft systems. Smartfusion2 has hardened
>> Microcontroller(Cortex-M3)based Sub System and FPGA fabric.
>> At the moment only system timer, sysreg and SPI
>> controller are modelled.
>>
>> Testing:
>> ./arm-softmmu/qemu-system-arm -M smartfusion2-som -serial mon:stdio \
>> -kernel u-boot.bin -display none -drive file=spi.bin,if=mtd,format=raw
>>
>> Binaries u-boot.bin and spi.bin are at:
>> https://github.com/Subbaraya-Sundeep/qemu-test-binaries.git
>>
>> U-boot is from Emcraft with modified
>> - SPI driver not to use PDMA.
>> - ugly hack to pass dtb to kernel in r1.
>> @
>> https://github.com/Subbaraya-Sundeep/emcraft-uboot-sf2.git
>>
>> Linux is 4.5 linux with Smartfusion2 SoC dts and clocksource
>> driver added by myself @
>> https://github.com/Subbaraya-Sundeep/linux.git
>>
>> v5
>> As per Philippe comments:
>> Added abort in Sysreg if guest tries to remap memory
>> other than default mapping.
>> Use of CONFIG_MSF2 in Makefile for soc.c
>> Fixed incorrect logic in timer model.
>> Renamed msf2-timer.c -> mss-timer.c
>> msf2-spi.c -> mss-spi.c also type names
>> Renamed function msf2_init->emcraft_sf2_init in msf2-som.c
>> Added part-name,eNVM-size,eSRAM-size,pclk0 and pclk1
>> properties to soc.
>> Pass soc part-name,memory size and clock rate properties from som.
>> v4:
>> Fixed build failure by using PRIx macros.
>> v3:
>> Added SoC file and board file as per Alistair comments.
>> v2:
>> Added SPI controller so that u-boot loads kernel from spi flash.
>> v1:
>> Initial patch set with timer and sysreg
>>
>> Thanks,
>> Sundeep
>>
>> Subbaraya Sundeep (5):
>>   msf2: Add Smartfusion2 System timer
>>   msf2: Microsemi Smartfusion2 System Register block.
>>   msf2: Add Smartfusion2 SPI controller
>>   msf2: Add Smartfusion2 SoC.
>>   msf2: Add Emcraft's Smartfusion2 SOM kit.
>>
>>  default-configs/arm-softmmu.mak |   1 +
>>  hw/arm/Makefile.objs|   2 +
>>  hw/arm/msf2-soc.c   | 201 +
>>  hw/arm/msf2-som.c   |  89 ++
>>  hw/misc/Makefile.objs   |   1 +
>>  hw/misc/msf2-sysreg.c   | 161 +
>>  hw/ssi/Makefile.objs|   1 +
>>  hw/ssi/mss-spi.c| 378 ++
>> ++
>>  hw/timer/Makefile.objs  |   1 +
>>  hw/timer/mss-timer.c| 249 ++
>>  include/hw/arm/msf2-soc.h   |  69 
>>  include/hw/misc/msf2-sysreg.h   |  80 +
>>  include/hw/ssi/mss-spi.h| 104 +++
>>  include/hw/timer/mss-timer.h|  80 +
>>  14 files changed, 1417 insertions(+)
>>  create mode 100644 hw/arm/msf2-soc.c
>>  create mode 100644 hw/arm/msf2-som.c
>>  create mode 100644 hw/misc/msf2-sysreg.c
>>  create mode 100644 hw/ssi/mss-spi.c
>>  create mode 100644 hw/timer/mss-timer.c
>>  create mode 100644 include/hw/arm/msf2-soc.h
>>  create mode 100644 include/hw/misc/msf2-sysreg.h
>>  create mode 100644 include/hw/ssi/mss-spi.h
>>  create mode 100644 include/hw/timer/mss-timer.h
>>
>>

Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request

[Halil Pasic]

On 05/17/2017 11:12 AM, Gonglei (Arei) wrote:
 By the way, I'm having a hard time understing how is the requirement form

>> http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-260
 004
 (2.4.4 Message Framing) satisfied by this code. Could you explain this
 to me please?

>>> Sorry for my bad English,
>>> I don't know which normative formulation the code violates?
>> I'm not sure it's actually violated, but I'm concerned about the following
>> normative statement: "The device MUST NOT make assumptions about the
>> particular
>> arrangement of descriptors. The device MAY have a reasonable limit of
>> descriptors it will allow in a chain."
>>
>> Please also read the explanatory part I've linked, because the normative
>> statement is pretty abstract.
>>
>> In my understanding, the spec says, that e.g. the virti-crypto device
>> should not fail if a single request is split up into let's say two chunks
>> and transmitted by the means of two top level descriptors.
>>
>> Do you agree with my reading of the spec?
>>
> Yes, I agree. But what's the relationship about the request here?
> We don't assume the request have to use one desc entity, it can
> use scatter-gather list for one request header. 
> The device can cover the situation in the QEMU. 
> 
>> What does the virtio-crypto device do if it encounters such a situation?
>>
> This isn't a problem. Pls see blow code segment:
> 
> virtio_crypto_handle_request()
> {...
> if (unlikely(iov_to_buf(out_iov, out_num, 0, &req, sizeof(req))
> != sizeof(req))) {
> virtio_error(vdev, "virtio-crypto request outhdr too short");
> return -1;
> }
> iov_discard_front(&out_iov, &out_num, sizeof(req));
> ...
> 

Thats exactly what worries me. I see a call to virtio_error there...


void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice *vdev, const char *fmt, ...)
{
va_list ap;

va_start(ap, fmt);
error_vreport(fmt, ap);
va_end(ap);

vdev->broken = true;

if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
virtio_set_status(vdev, vdev->status | VIRTIO_CONFIG_S_NEEDS_RESET);
virtio_notify_config(vdev);
}
}

This however seems to make the device 'broken'. Or am I missing something?

Halil

> 
> Thanks,
> -Gonglei
> 

Re: [Qemu-devel] [PULL 19/48] spapr: allocate the ICPState object from under sPAPRCPUCore

[Greg Kurz]

On Wed, 17 May 2017 07:50:42 +0200
Cédric Le Goater  wrote:

> On 05/16/2017 06:10 PM, Greg Kurz wrote:
> > On Tue, 16 May 2017 17:18:27 +0200
> > Cédric Le Goater  wrote:
> >   
> >> On 05/16/2017 02:55 PM, Laurent Vivier wrote:  
> >>> On 16/05/2017 14:50, Cédric Le Goater wrote:
>  On 05/16/2017 02:03 PM, Laurent Vivier wrote:
> > On 26/04/2017 09:00, David Gibson wrote:
> >> From: Cédric Le Goater 
> >>
> >> Today, all the ICPs are created before the CPUs, stored in an array
> >> under the sPAPR machine and linked to the CPU when the core threads
> >> are realized. This modeling brings some complexity when a lookup in
> >> the array is required and it can be simplified by allocating the ICPs
> >> when the CPUs are.
> >>
> >> This is the purpose of this proposal which introduces a new 'icp_type'
> >> field under the machine and creates the ICP objects of the right type
> >> (KVM or not) before the PowerPCCPU object are.
> >>
> >> This change allows more cleanups : the removal of the icps array under
> >> the sPAPR machine and the removal of the xics_get_cpu_index_by_dt_id()
> >> helper.
> >>
> >> Signed-off-by: Cédric Le Goater 
> >> Reviewed-by: David Gibson 
> >> Signed-off-by: David Gibson 
> >> ---
> >>  hw/intc/xics.c  | 11 ---
> >>  hw/ppc/spapr.c  | 47 
> >> ++-
> >>  hw/ppc/spapr_cpu_core.c | 18 ++
> >>  include/hw/ppc/spapr.h  |  2 +-
> >>  include/hw/ppc/xics.h   |  2 --
> >>  5 files changed, 29 insertions(+), 51 deletions(-)
> >>
> >
> > This commit breaks CPU re-hotplugging with KVM
> >
> > the sequence "device_add, device_del, device_add" brings to the
> > following error message:
> >
> > Unable to connect CPUx to kernel XICS: Device or resource busy
> >
> > It comes from icp_kvm_cpu_setup():
> >
> > ...
> > ret = kvm_vcpu_enable_cap(cs, KVM_CAP_IRQ_XICS, 0, kernel_xics_fd,
> >   kvm_arch_vcpu_id(cs));
> > if (ret < 0) {
> > error_report("Unable to connect CPU%ld to kernel XICS: %s",
> >  kvm_arch_vcpu_id(cs), strerror(errno));
> > exit(1);
> > }
> > ..
> >
> > It should be protected by cap_irq_xics_enabled:
> >
> > ...
> > /*
> >  * If we are reusing a parked vCPU fd corresponding to the CPU
> >  * which was hot-removed earlier we don't have to renable
> >  * KVM_CAP_IRQ_XICS capability again.
> >  */
> > if (icp->cap_irq_xics_enabled) {
> > return;
> > }
> >
> > ...
> > ret = kvm_vcpu_enable_cap(...);
> > ...
> > icp->cap_irq_xics_enabled = true;
> > ...
> >
> > But since this commit, "icp" is a new object on each call:
> >
> > spapr_cpu_core_realize_child()
> > ...
> > obj = object_new(spapr->icp_type);
> > ...
> > xics_cpu_setup(XICS_FABRIC(spapr), cpu, ICP(obj));
> > ...
> > icpc->cpu_setup(icp, cpu); -> icp_kvm_cpu_setup()
> > ...
> > ...
> >
> > and "cap_irq_xics_enabled" is reinitialized.
> >
> > Any idea how to fix that?
> 
>  it seems that a cleanup is not done in the kernel. We are missing
>  a way to call kvmppc_xics_free_icp() from QEMU. Today the only
>  way is to destroy the vcpu. 
> >>>
> >>> The commit introducing this hack, for reference:
> >>>
> >>> commit a45863bda90daa8ec39e5a312b9734fd4665b016
> >>> Author: Bharata B Rao 
> >>> Date:   Thu Jul 2 16:23:20 2015 +1000
> >>>
> >>> xics_kvm: Don't enable KVM_CAP_IRQ_XICS if already enabled
> >>> 
> >>> When supporting CPU hot removal by parking the vCPU fd and reusing
> >>> it during hotplug again, there can be cases where we try to reenable
> >>> KVM_CAP_IRQ_XICS CAP for the vCPU for which it was already enabled.
> >>> Introduce a boolean member in ICPState to track this and don't
> >>> reenable the CAP if it was already enabled earlier.
> >>> 
> >>> Re-enabling this CAP should ideally work, but currently it results in
> >>> kernel trying to create and associate ICP with this vCPU and that
> >>> fails since there is already an ICP associated with it. Hence this
> >>> patch is needed to work around this problem in the kernel.
> >>> 
> >>> This change allows CPU hot removal to work for sPAPR.
> >>> 
> >>> Signed-off-by: Bharata B Rao 
> >>> Reviewed-by: David Gibson 
> >>> Signed-off-by: David Gibson 
> >>> Signed-off-by: Alexander Graf 
> >>
> >> OK. 
> >>
> >> Greg is looking at re-adding the ICPState array because of a 
> >> migration issue with older machines. We might need to do so 
> >> unconditionally ...
> >>  
> > 
> > That would be a pity 

Re: [Qemu-devel] [Qemu-ppc] [PULL 19/48] spapr: allocate the ICPState object from under sPAPRCPUCore

[Greg Kurz]

On Wed, 17 May 2017 16:37:52 +1000
David Gibson  wrote:
[...]
> > >>
> > >> Greg is looking at re-adding the ICPState array because of a 
> > >> migration issue with older machines. We might need to do so 
> > >> unconditionally ...
> > >>  
> > > 
> > > That would be a pity to carry on with the pre-allocated ICPStates for
> > > new machine types just because of that... What about keeping track
> > > of all the cap_irq_xics_enabled flags in a separate max_cpus sized
> > > static array ?  
> > 
> > Could we use 'cpu->unplug' instead ?  
> 
> I've only half followed this discussion, but fwiw I prefer the idea of
> "parking" in-kernel ICP objects, similarly to the way we do for
> removed VCPUs, rather than going back to keeping ICP objects around
> indefinitely and unconditionally.
> 

I'll give a try.

Cheers,

--
Greg


pgpMReY9pyBda.pgp
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC PATCH v1 1/6] migration: Fix unregister_savevm()

[Bharata B Rao]

On Wed, May 17, 2017 at 04:43:00PM +1000, David Gibson wrote:
> On Wed, May 17, 2017 at 09:19:17AM +0530, Bharata B Rao wrote:
> > In unregister_savevm(), free se->compat only if it was allocated earlier.
> > 
> > Signed-off-by: Bharata B Rao 
> 
> I don't think this is necessary.  If se->compat was never allocated,
> then it should be NULL (since se is allocated with g_new0()).
> g_free() is explicitly safe to call on NULL, and we already rely on
> that in qemu.

Yeah, this is not necessary, will get rid of this in the next iteration.

Regards.,
Bharata.

Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request

[Gonglei (Arei)]

> 
> On 05/17/2017 11:12 AM, Gonglei (Arei) wrote:
>  By the way, I'm having a hard time understing how is the requirement
> form
> 
> >>
> http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-260
>  004
>  (2.4.4 Message Framing) satisfied by this code. Could you explain this
>  to me please?
> 
> >>> Sorry for my bad English,
> >>> I don't know which normative formulation the code violates?
> >> I'm not sure it's actually violated, but I'm concerned about the following
> >> normative statement: "The device MUST NOT make assumptions about the
> >> particular
> >> arrangement of descriptors. The device MAY have a reasonable limit of
> >> descriptors it will allow in a chain."
> >>
> >> Please also read the explanatory part I've linked, because the normative
> >> statement is pretty abstract.
> >>
> >> In my understanding, the spec says, that e.g. the virti-crypto device
> >> should not fail if a single request is split up into let's say two chunks
> >> and transmitted by the means of two top level descriptors.
> >>
> >> Do you agree with my reading of the spec?
> >>
> > Yes, I agree. But what's the relationship about the request here?
> > We don't assume the request have to use one desc entity, it can
> > use scatter-gather list for one request header.
> > The device can cover the situation in the QEMU.
> >
> >> What does the virtio-crypto device do if it encounters such a situation?
> >>
> > This isn't a problem. Pls see blow code segment:
> >
> > virtio_crypto_handle_request()
> > {...
> > if (unlikely(iov_to_buf(out_iov, out_num, 0, &req, sizeof(req))
> > != sizeof(req))) {
> > virtio_error(vdev, "virtio-crypto request outhdr too short");
> > return -1;
> > }
> > iov_discard_front(&out_iov, &out_num, sizeof(req));
> > ...
> >
> 
> Thats exactly what worries me. I see a call to virtio_error there...
> 
> 
> void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice *vdev, const char *fmt, ...)
> {
> va_list ap;
> 
> va_start(ap, fmt);
> error_vreport(fmt, ap);
> va_end(ap);
> 
> vdev->broken = true;
> 
> if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> virtio_set_status(vdev, vdev->status |
> VIRTIO_CONFIG_S_NEEDS_RESET);
> virtio_notify_config(vdev);
> }
> }
> 
> This however seems to make the device 'broken'. Or am I missing something?
> 
Yes, if the parse process failed, the device will broke. 
But This is a exception scenario IMHO, which is the same situation
with other virtio devices. 

Stefan introduced the virtio_error().

Thanks,
-Gonglei

[Qemu-devel] [PATCH 2/2] xhci: add CONFIG_USB_XHCI_NEC option

[Gerd Hoffmann]

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1451189
Signed-off-by: Gerd Hoffmann 
---
 default-configs/pci.mak | 1 +
 hw/usb/Makefile.objs| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/default-configs/pci.mak b/default-configs/pci.mak
index 60dc6510ec..3bbeb62d9a 100644
--- a/default-configs/pci.mak
+++ b/default-configs/pci.mak
@@ -7,6 +7,7 @@ CONFIG_USB_UHCI=y
 CONFIG_USB_OHCI=y
 CONFIG_USB_EHCI=y
 CONFIG_USB_XHCI=y
+CONFIG_USB_XHCI_NEC=y
 CONFIG_NE2000_PCI=y
 CONFIG_EEPRO100_PCI=y
 CONFIG_PCNET_PCI=y
diff --git a/hw/usb/Makefile.objs b/hw/usb/Makefile.objs
index 249106f32d..97f1c4561a 100644
--- a/hw/usb/Makefile.objs
+++ b/hw/usb/Makefile.objs
@@ -8,7 +8,7 @@ common-obj-$(CONFIG_USB_OHCI) += hcd-ohci.o
 common-obj-$(CONFIG_USB_EHCI) += hcd-ehci.o hcd-ehci-pci.o
 common-obj-$(CONFIG_USB_EHCI_SYSBUS) += hcd-ehci-sysbus.o
 common-obj-$(CONFIG_USB_XHCI) += hcd-xhci.o
-common-obj-$(CONFIG_USB_XHCI) += hcd-xhci-nec.o
+common-obj-$(CONFIG_USB_XHCI_NEC) += hcd-xhci-nec.o
 common-obj-$(CONFIG_USB_MUSB) += hcd-musb.o
 
 obj-$(CONFIG_TUSB6010) += tusb6010.o
-- 
2.9.3

Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request

[Halil Pasic]

On 05/17/2017 12:13 PM, Gonglei (Arei) wrote:
>>
>> On 05/17/2017 11:12 AM, Gonglei (Arei) wrote:
>> By the way, I'm having a hard time understing how is the requirement
>> form
>>

>> http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-260
>> 004
>> (2.4.4 Message Framing) satisfied by this code. Could you explain this
>> to me please?
>>
> Sorry for my bad English,
> I don't know which normative formulation the code violates?
 I'm not sure it's actually violated, but I'm concerned about the following
 normative statement: "The device MUST NOT make assumptions about the
 particular
 arrangement of descriptors. The device MAY have a reasonable limit of
 descriptors it will allow in a chain."

 Please also read the explanatory part I've linked, because the normative
 statement is pretty abstract.

 In my understanding, the spec says, that e.g. the virti-crypto device
 should not fail if a single request is split up into let's say two chunks
 and transmitted by the means of two top level descriptors.

 Do you agree with my reading of the spec?

>>> Yes, I agree. But what's the relationship about the request here?
>>> We don't assume the request have to use one desc entity, it can
>>> use scatter-gather list for one request header.
>>> The device can cover the situation in the QEMU.
>>>
 What does the virtio-crypto device do if it encounters such a situation?

>>> This isn't a problem. Pls see blow code segment:
>>>
>>> virtio_crypto_handle_request()
>>> {...
>>> if (unlikely(iov_to_buf(out_iov, out_num, 0, &req, sizeof(req))
>>> != sizeof(req))) {
>>> virtio_error(vdev, "virtio-crypto request outhdr too short");
>>> return -1;
>>> }
>>> iov_discard_front(&out_iov, &out_num, sizeof(req));
>>> ...
>>>
>>
>> Thats exactly what worries me. I see a call to virtio_error there...
>>
>>
>> void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice *vdev, const char *fmt, 
>> ...)
>> {
>> va_list ap;
>>
>> va_start(ap, fmt);
>> error_vreport(fmt, ap);
>> va_end(ap);
>>
>> vdev->broken = true;
>>
>> if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
>> virtio_set_status(vdev, vdev->status |
>> VIRTIO_CONFIG_S_NEEDS_RESET);
>> virtio_notify_config(vdev);
>> }
>> }
>>
>> This however seems to make the device 'broken'. Or am I missing something?
>>
> Yes, if the parse process failed, the device will broke. 
> But This is a exception scenario IMHO, which is the same situation
> with other virtio devices. 

I know that virtio-blk does the same. I'm not sure my reading of the
spec is correct. Maybe Stefan, Michael or Connie can clarify this
for us!

By the way for virtio-blk the current handling was introduced by
commit 20ea686a0 (by Greg Kurz), but before we were failing even harder.

Regards,
Halil

> 
> Stefan introduced the virtio_error().
> 
> Thanks,
> -Gonglei
> 

[Qemu-devel] [PATCH 1/2] xhci: split into multiple files

[Gerd Hoffmann]

Moved structs and defines to hcd-xhci.h.
Move nec controller variant to hcd-xhci-nec.c.
No functional changes.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb/hcd-xhci.h | 226 +++
 hw/usb/hcd-xhci-nec.c |  63 +
 hw/usb/hcd-xhci.c | 238 +-
 hw/usb/Makefile.objs  |   1 +
 4 files changed, 292 insertions(+), 236 deletions(-)
 create mode 100644 hw/usb/hcd-xhci.h
 create mode 100644 hw/usb/hcd-xhci-nec.c

diff --git a/hw/usb/hcd-xhci.h b/hw/usb/hcd-xhci.h
new file mode 100644
index 00..fc36a4c787
--- /dev/null
+++ b/hw/usb/hcd-xhci.h
@@ -0,0 +1,226 @@
+/*
+ * USB xHCI controller emulation
+ *
+ * Copyright (c) 2011 Securiforest
+ * Date: 2011-05-11 ;  Author: Hector Martin 
+ * Based on usb-ohci.c, emulates Renesas NEC USB 3.0
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ */
+
+#define TYPE_XHCI "base-xhci"
+#define TYPE_NEC_XHCI "nec-usb-xhci"
+#define TYPE_QEMU_XHCI "qemu-xhci"
+
+#define XHCI(obj) \
+OBJECT_CHECK(XHCIState, (obj), TYPE_XHCI)
+
+#define MAXPORTS_2 15
+#define MAXPORTS_3 15
+
+#define MAXPORTS (MAXPORTS_2 + MAXPORTS_3)
+#define MAXSLOTS 64
+#define MAXINTRS 16
+
+/* Very pessimistic, let's hope it's enough for all cases */
+#define EV_QUEUE (((3 * 24) + 16) * MAXSLOTS)
+
+typedef struct XHCIState XHCIState;
+typedef struct XHCIStreamContext XHCIStreamContext;
+typedef struct XHCIEPContext XHCIEPContext;
+
+enum xhci_flags {
+XHCI_FLAG_SS_FIRST = 1,
+XHCI_FLAG_FORCE_PCIE_ENDCAP,
+XHCI_FLAG_ENABLE_STREAMS,
+};
+
+typedef enum TRBType {
+TRB_RESERVED = 0,
+TR_NORMAL,
+TR_SETUP,
+TR_DATA,
+TR_STATUS,
+TR_ISOCH,
+TR_LINK,
+TR_EVDATA,
+TR_NOOP,
+CR_ENABLE_SLOT,
+CR_DISABLE_SLOT,
+CR_ADDRESS_DEVICE,
+CR_CONFIGURE_ENDPOINT,
+CR_EVALUATE_CONTEXT,
+CR_RESET_ENDPOINT,
+CR_STOP_ENDPOINT,
+CR_SET_TR_DEQUEUE,
+CR_RESET_DEVICE,
+CR_FORCE_EVENT,
+CR_NEGOTIATE_BW,
+CR_SET_LATENCY_TOLERANCE,
+CR_GET_PORT_BANDWIDTH,
+CR_FORCE_HEADER,
+CR_NOOP,
+ER_TRANSFER = 32,
+ER_COMMAND_COMPLETE,
+ER_PORT_STATUS_CHANGE,
+ER_BANDWIDTH_REQUEST,
+ER_DOORBELL,
+ER_HOST_CONTROLLER,
+ER_DEVICE_NOTIFICATION,
+ER_MFINDEX_WRAP,
+/* vendor specific bits */
+CR_VENDOR_NEC_FIRMWARE_REVISION  = 49,
+CR_VENDOR_NEC_CHALLENGE_RESPONSE = 50,
+} TRBType;
+
+typedef enum TRBCCode {
+CC_INVALID = 0,
+CC_SUCCESS,
+CC_DATA_BUFFER_ERROR,
+CC_BABBLE_DETECTED,
+CC_USB_TRANSACTION_ERROR,
+CC_TRB_ERROR,
+CC_STALL_ERROR,
+CC_RESOURCE_ERROR,
+CC_BANDWIDTH_ERROR,
+CC_NO_SLOTS_ERROR,
+CC_INVALID_STREAM_TYPE_ERROR,
+CC_SLOT_NOT_ENABLED_ERROR,
+CC_EP_NOT_ENABLED_ERROR,
+CC_SHORT_PACKET,
+CC_RING_UNDERRUN,
+CC_RING_OVERRUN,
+CC_VF_ER_FULL,
+CC_PARAMETER_ERROR,
+CC_BANDWIDTH_OVERRUN,
+CC_CONTEXT_STATE_ERROR,
+CC_NO_PING_RESPONSE_ERROR,
+CC_EVENT_RING_FULL_ERROR,
+CC_INCOMPATIBLE_DEVICE_ERROR,
+CC_MISSED_SERVICE_ERROR,
+CC_COMMAND_RING_STOPPED,
+CC_COMMAND_ABORTED,
+CC_STOPPED,
+CC_STOPPED_LENGTH_INVALID,
+CC_MAX_EXIT_LATENCY_TOO_LARGE_ERROR = 29,
+CC_ISOCH_BUFFER_OVERRUN = 31,
+CC_EVENT_LOST_ERROR,
+CC_UNDEFINED_ERROR,
+CC_INVALID_STREAM_ID_ERROR,
+CC_SECONDARY_BANDWIDTH_ERROR,
+CC_SPLIT_TRANSACTION_ERROR
+} TRBCCode;
+
+typedef struct XHCIRing {
+dma_addr_t dequeue;
+bool ccs;
+} XHCIRing;
+
+typedef struct XHCIPort {
+XHCIState *xhci;
+uint32_t portsc;
+uint32_t portnr;
+USBPort  *uport;
+uint32_t speedmask;
+char name[16];
+MemoryRegion mem;
+} XHCIPort;
+
+typedef struct XHCISlot {
+bool enabled;
+bool addressed;
+dma_addr_t ctx;
+USBPort *uport;
+XHCIEPContext *eps[31];
+} XHCISlot;
+
+typedef struct XHCIEvent {
+TRBType type;
+TRBCCode ccode;
+uint64_t ptr;
+uint32_t length;
+uint32_t flags;
+uint8_t slotid;
+uint8_t epid;
+} XHCIEvent;
+
+typedef struct XHCIInterrupter {
+uint32_t iman;
+uint32_t imod;
+uint32_t erstsz;
+uint32_t erstba_low;
+uint32_t erstba_high;
+uint32_t erdp_low;
+uint32_t erdp_high;
+
+bool msix_used, er_pcs;
+
+dma_addr_t er_start;
+uint32_t er_size;
+unsigned int er_ep_idx;

Re: [Qemu-devel] [PATCH 12/17] qdev: use int and uint properties as appropriate

[Markus Armbruster]

Marc-André Lureau  writes:

> Use unsigned type for various properties.
>
> Signed-off-by: Marc-André Lureau 
> ---
>  include/hw/qdev-core.h   |  5 +++-
>  include/hw/qdev-properties.h | 67 
> ++--
>  hw/block/fdc.c   | 54 +--
>  hw/core/qdev-properties.c|  8 +++---
>  hw/core/qdev.c   | 24 ++--
>  hw/net/e1000e.c  | 14 -
>  6 files changed, 96 insertions(+), 76 deletions(-)
>
> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> index 0f21a500cd..ac10458650 100644
> --- a/include/hw/qdev-core.h
> +++ b/include/hw/qdev-core.h
> @@ -225,7 +225,10 @@ struct Property {
>  PropertyInfo *info;
>  ptrdiff_toffset;
>  uint8_t  bitnr;
> -int64_t  defval;
> +union {
> +int64_t i;
> +uint64_t u;
> +} defval;

Could also simply make it uint64_t.  Converting a negative integer to
uint64_t adds 2^64 (See ISO/IEC 9899:1999 §6.3.1.3).  Converting back is
implementation-defined (ibid.), but in practice it yields the same
signed integer (loads of code relies on that).  Matter of taste.

>  int  arrayoffset;
>  PropertyInfo *arrayinfo;
>  int  arrayfieldsize;
> diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
> index 16d5d0629b..ca9c550fa3 100644
> --- a/include/hw/qdev-properties.h
> +++ b/include/hw/qdev-properties.h
> @@ -37,36 +37,47 @@ extern PropertyInfo qdev_prop_arraylen;
>  .offset= offsetof(_state, _field)\
>  + type_check(_type, typeof_field(_state, _field)),   \
>  }
> -#define DEFINE_PROP_DEFAULT(_name, _state, _field, _defval, _prop, _type) { \
> +
> +#define DEFINE_PROP_INT(_name, _state, _field, _defval, _prop, _type) { \
>  .name  = (_name),   \
>  .info  = &(_prop),  \
>  .offset= offsetof(_state, _field)   \
>  + type_check(_type,typeof_field(_state, _field)),   \
> -.defval= (_type)_defval,\
> +.defval.i  = (_type)_defval,\
>  }

Doing the rename in a separate patch would make review a bit easier.
Not worth splitting now, but consider it next time.

> -#define DEFINE_PROP_BIT(_name, _state, _field, _bit, _defval) {  \
> -.name  = (_name),\
> -.info  = &(qdev_prop_bit),   \
> -.bitnr= (_bit),  \
> -.offset= offsetof(_state, _field)\
> -+ type_check(uint32_t,typeof_field(_state, _field)), \
> -.defval= (bool)_defval,  \
> +
> +#define DEFINE_PROP_BIT(_name, _state, _field, _bit, _defval) { \
> +.name  = (_name),   \
> +.info  = &(qdev_prop_bit),  \
> +.bitnr= (_bit), \
> +.offset= offsetof(_state, _field)   \
> ++ type_check(uint32_t, typeof_field(_state, _field)),\
> +.defval.u   = (bool)_defval,\
>  }
> +
> +#define DEFINE_PROP_UINT(_name, _state, _field, _defval, _prop, _type) { \
> +.name  = (_name),   \
> +.info  = &(_prop),  \
> +.offset= offsetof(_state, _field)   \
> ++ type_check(_type, typeof_field(_state, _field)),  \
> +.defval.u  = (_type)_defval,\
> +}
> +
>  #define DEFINE_PROP_BIT64(_name, _state, _field, _bit, _defval) {   \
>  .name  = (_name),   \
>  .info  = &(qdev_prop_bit64),\
>  .bitnr= (_bit), \
>  .offset= offsetof(_state, _field)   \
>  + type_check(uint64_t, typeof_field(_state, _field)),   \
> -.defval= (bool)_defval, \
> +.defval.u  = (bool)_defval, \
>  }
>  
> -#define DEFINE_PROP_BOOL(_name, _state, _field, _defval) {   \
> -.name  = (_name),\
> -.info  = &(qdev_prop_bool),  \
> -.offset= offsetof(_state, _field)\
> -+ type_check(bool, typeof_field(_state, _field)),\
> -.defval= (bool)_defval

Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request

[Cornelia Huck]

On Wed, 17 May 2017 12:33:20 +0200
Halil Pasic  wrote:

> On 05/17/2017 12:13 PM, Gonglei (Arei) wrote:
> >>
> >> On 05/17/2017 11:12 AM, Gonglei (Arei) wrote:
> >> By the way, I'm having a hard time understing how is the requirement
> >> form
> >>
> 
> >> http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-260
> >> 004
> >> (2.4.4 Message Framing) satisfied by this code. Could you explain this
> >> to me please?
> >>
> > Sorry for my bad English,
> > I don't know which normative formulation the code violates?
>  I'm not sure it's actually violated, but I'm concerned about the 
>  following
>  normative statement: "The device MUST NOT make assumptions about the
>  particular
>  arrangement of descriptors. The device MAY have a reasonable limit of
>  descriptors it will allow in a chain."
> 
>  Please also read the explanatory part I've linked, because the normative
>  statement is pretty abstract.
> 
>  In my understanding, the spec says, that e.g. the virti-crypto device
>  should not fail if a single request is split up into let's say two chunks
>  and transmitted by the means of two top level descriptors.
> 
>  Do you agree with my reading of the spec?
> 
> >>> Yes, I agree. But what's the relationship about the request here?
> >>> We don't assume the request have to use one desc entity, it can
> >>> use scatter-gather list for one request header.
> >>> The device can cover the situation in the QEMU.
> >>>
>  What does the virtio-crypto device do if it encounters such a situation?
> 
> >>> This isn't a problem. Pls see blow code segment:
> >>>
> >>> virtio_crypto_handle_request()
> >>> {...
> >>> if (unlikely(iov_to_buf(out_iov, out_num, 0, &req, sizeof(req))
> >>> != sizeof(req))) {
> >>> virtio_error(vdev, "virtio-crypto request outhdr too short");
> >>> return -1;
> >>> }
> >>> iov_discard_front(&out_iov, &out_num, sizeof(req));
> >>> ...
> >>>
> >>
> >> Thats exactly what worries me. I see a call to virtio_error there...
> >>
> >>
> >> void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice *vdev, const char *fmt, 
> >> ...)
> >> {
> >> va_list ap;
> >>
> >> va_start(ap, fmt);
> >> error_vreport(fmt, ap);
> >> va_end(ap);
> >>
> >> vdev->broken = true;
> >>
> >> if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> >> virtio_set_status(vdev, vdev->status |
> >> VIRTIO_CONFIG_S_NEEDS_RESET);
> >> virtio_notify_config(vdev);
> >> }
> >> }
> >>
> >> This however seems to make the device 'broken'. Or am I missing something?
> >>
> > Yes, if the parse process failed, the device will broke. 
> > But This is a exception scenario IMHO, which is the same situation
> > with other virtio devices. 
> 
> I know that virtio-blk does the same. I'm not sure my reading of the
> spec is correct. Maybe Stefan, Michael or Connie can clarify this
> for us!

The spec says for NEEDS_RESET:

"Indicates that the device has experienced an error from which it can't
recover."

For me, this means:
- If this is something that might happen in the normal course of events
and there's a good recovery path, just recover.
- Else, use virtio_error() and require the driver to recover via reset.

If the driver is sending requests in an unexpected format, I'd use
virtio_error(). The format needs to be properly described, though.

> 
> By the way for virtio-blk the current handling was introduced by
> commit 20ea686a0 (by Greg Kurz), but before we were failing even
> harder.
> 
> Regards,
> Halil
> 
> > 
> > Stefan introduced the virtio_error().
> > 
> > Thanks,
> > -Gonglei
> > 

[Qemu-devel] [PATCH v4 1/3] net/rocker: Remove the dead error handling

[Mao Zhongyi]

The function of_dpa_world_alloc is a wrapper around world_alloc(), which
returns null only when g_malloc0(size_t size) does. But g_malloc0() also
is a wrapper around g_malloc0_n(1, size) that ignore the fact that
g_malloc0() of 0 bytes, it doesn't returns null. So the error handling is
dead. Similar like desc_ring_alloc(), fp_port_alloc() etc. Remove these
entirely.

Cc: jasow...@redhat.com
Cc: j...@resnulli.us
Cc: f4...@amsat.org
Cc: arm...@redhat.com
Signed-off-by: Mao Zhongyi 
---
 hw/net/rocker/rocker.c  | 32 
 hw/net/rocker/rocker_desc.c |  3 ---
 hw/net/rocker/rocker_fp.c   |  4 
 3 files changed, 39 deletions(-)

diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
index 6e70fdd..b2b6dc7 100644
--- a/hw/net/rocker/rocker.c
+++ b/hw/net/rocker/rocker.c
@@ -1313,13 +1313,6 @@ static int pci_rocker_init(PCIDevice *dev)
 
 r->worlds[ROCKER_WORLD_TYPE_OF_DPA] = of_dpa_world_alloc(r);
 
-for (i = 0; i < ROCKER_WORLD_TYPE_MAX; i++) {
-if (!r->worlds[i]) {
-err = -ENOMEM;
-goto err_world_alloc;
-}
-}
-
 if (!r->world_name) {
 r->world_name = 
g_strdup(world_name(r->worlds[ROCKER_WORLD_TYPE_OF_DPA]));
 }
@@ -1396,9 +1389,6 @@ static int pci_rocker_init(PCIDevice *dev)
 }
 
 r->rings = g_new(DescRing *, rocker_pci_ring_count(r));
-if (!r->rings) {
-goto err_rings_alloc;
-}
 
 /* Rings are ordered like this:
  * - command ring
@@ -1410,14 +1400,9 @@ static int pci_rocker_init(PCIDevice *dev)
  * .
  */
 
-err = -ENOMEM;
 for (i = 0; i < rocker_pci_ring_count(r); i++) {
 DescRing *ring = desc_ring_alloc(r, i);
 
-if (!ring) {
-goto err_ring_alloc;
-}
-
 if (i == ROCKER_RING_CMD) {
 desc_ring_set_consume(ring, cmd_consume, ROCKER_MSIX_VEC_CMD);
 } else if (i == ROCKER_RING_EVENT) {
@@ -1437,10 +1422,6 @@ static int pci_rocker_init(PCIDevice *dev)
 fp_port_alloc(r, r->name, &r->fp_start_macaddr,
   i, &r->fp_ports_peers[i]);
 
-if (!port) {
-goto err_port_alloc;
-}
-
 r->fp_port[i] = port;
 fp_port_set_world(port, r->world_dflt);
 }
@@ -1449,25 +1430,12 @@ static int pci_rocker_init(PCIDevice *dev)
 
 return 0;
 
-err_port_alloc:
-for (--i; i >= 0; i--) {
-FpPort *port = r->fp_port[i];
-fp_port_free(port);
-}
-i = rocker_pci_ring_count(r);
-err_ring_alloc:
-for (--i; i >= 0; i--) {
-desc_ring_free(r->rings[i]);
-}
-g_free(r->rings);
-err_rings_alloc:
 err_duplicate:
 rocker_msix_uninit(r);
 err_msix_init:
 object_unparent(OBJECT(&r->msix_bar));
 object_unparent(OBJECT(&r->mmio));
 err_world_type_by_name:
-err_world_alloc:
 for (i = 0; i < ROCKER_WORLD_TYPE_MAX; i++) {
 if (r->worlds[i]) {
 world_free(r->worlds[i]);
diff --git a/hw/net/rocker/rocker_desc.c b/hw/net/rocker/rocker_desc.c
index ac02797..bd7e364 100644
--- a/hw/net/rocker/rocker_desc.c
+++ b/hw/net/rocker/rocker_desc.c
@@ -347,9 +347,6 @@ DescRing *desc_ring_alloc(Rocker *r, int index)
 DescRing *ring;
 
 ring = g_new0(DescRing, 1);
-if (!ring) {
-return NULL;
-}
 
 ring->r = r;
 ring->index = index;
diff --git a/hw/net/rocker/rocker_fp.c b/hw/net/rocker/rocker_fp.c
index 1305ac3..4b3c984 100644
--- a/hw/net/rocker/rocker_fp.c
+++ b/hw/net/rocker/rocker_fp.c
@@ -226,10 +226,6 @@ FpPort *fp_port_alloc(Rocker *r, char *sw_name,
 {
 FpPort *port = g_new0(FpPort, 1);
 
-if (!port) {
-return NULL;
-}
-
 port->r = r;
 port->index = index;
 port->pport = index + 1;
-- 
2.9.3

[Qemu-devel] [PATCH v4 0/3] Convert to realize and fix error handling

[Mao Zhongyi]

v4:
* Patch 1 is following Markus's suggestion that remove the dead error
  handling.
* Patch 2 is separate from patch 1 to plug the memory leak in the v3.
* Patch 3 is based on the patch 1 in the v3. Meanwhile, dorp the superfluous
  prefix "rocker:" and adjust the commit message.

v3:
* Following Jason's suggstion that add suitable error message to 
  each error site.
* Modified the commit message to make it easier to read.

v2:
* Following Philippe's suggestion that shorten the patch subject 
  "hw/net/rocker/rocker" to "net/rocker". 
* Use a consistent log format to report error message.
* Add a specific goto label "err_name_too_long" to make a correct
  cleanup.

Cc: jasow...@redhat.com
Cc: j...@resnulli.us
Cc: f4...@amsat.org
Cc: arm...@redhat.com
Mao Zhongyi (3):
  net/rocker: Remove the dead error handling
  net/rocker: Plug memory leak in pci_rocker_init()
  net/rocker: Convert to realize()

 hw/net/rocker/rocker.c  | 61 ++---
 hw/net/rocker/rocker_desc.c |  3 ---
 hw/net/rocker/rocker_fp.c   |  4 ---
 3 files changed, 13 insertions(+), 55 deletions(-)

-- 
2.9.3

[Qemu-devel] [PATCH v4 3/3] net/rocker: Convert to realize()

[Mao Zhongyi]

The rocker device still implements the old PCIDeviceClass .init()
instead of the new .realize(). All devices need to be converted to
.realize().

.init() reports errors with fprintf() and return 0 on success, negative
number on failure. Meanwhile, when -device rocker fails, it first report
a specific error, then a generic one, like this:

$ x86_64-softmmu/qemu-system-x86_64 -device rocker,name=qemu-rocker
rocker: name too long; please shorten to at most 9 chars
qemu-system-x86_64: -device rocker,name=qemu-rocker: Device initialization 
failed

Now, convert it to .realize() that passes errors to its callers via its
errp argument. Also avoid the superfluous second error message. After
the patch, effect like this:

$ x86_64-softmmu/qemu-system-x86_64 -device rocker,name=qemu-rocker
qemu-system-x86_64: -device rocker,name=qemu-rocker: name too long; please 
shorten to at most 9 chars

Cc: jasow...@redhat.com
Cc: j...@resnulli.us
Cc: f4...@amsat.org
Cc: arm...@redhat.com
Signed-off-by: Mao Zhongyi 
---
 hw/net/rocker/rocker.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
index a382a6f..b9a77f1 100644
--- a/hw/net/rocker/rocker.c
+++ b/hw/net/rocker/rocker.c
@@ -1252,20 +1252,18 @@ rollback:
 return err;
 }
 
-static int rocker_msix_init(Rocker *r)
+static int rocker_msix_init(Rocker *r, Error **errp)
 {
 PCIDevice *dev = PCI_DEVICE(r);
 int err;
-Error *local_err = NULL;
 
 err = msix_init(dev, ROCKER_MSIX_VEC_COUNT(r->fp_ports),
 &r->msix_bar,
 ROCKER_PCI_MSIX_BAR_IDX, ROCKER_PCI_MSIX_TABLE_OFFSET,
 &r->msix_bar,
 ROCKER_PCI_MSIX_BAR_IDX, ROCKER_PCI_MSIX_PBA_OFFSET,
-0, &local_err);
+0, errp);
 if (err) {
-error_report_err(local_err);
 return err;
 }
 
@@ -1301,7 +1299,7 @@ static World *rocker_world_type_by_name(Rocker *r, const 
char *name)
 return NULL;
 }
 
-static int pci_rocker_init(PCIDevice *dev)
+static void pci_rocker_realize(PCIDevice *dev, Error **errp)
 {
 Rocker *r = to_rocker(dev);
 const MACAddr zero = { .a = { 0, 0, 0, 0, 0, 0 } };
@@ -1319,10 +1317,9 @@ static int pci_rocker_init(PCIDevice *dev)
 
 r->world_dflt = rocker_world_type_by_name(r, r->world_name);
 if (!r->world_dflt) {
-fprintf(stderr,
-"rocker: requested world \"%s\" does not exist\n",
+error_setg(errp,
+"invalid argument requested world %s does not exist",
 r->world_name);
-err = -EINVAL;
 goto err_world_type_by_name;
 }
 
@@ -1342,7 +1339,7 @@ static int pci_rocker_init(PCIDevice *dev)
 
 /* MSI-X init */
 
-err = rocker_msix_init(r);
+err = rocker_msix_init(r, errp);
 if (err) {
 goto err_msix_init;
 }
@@ -1354,7 +1351,7 @@ static int pci_rocker_init(PCIDevice *dev)
 }
 
 if (rocker_find(r->name)) {
-err = -EEXIST;
+error_setg(errp, "%s already exists", r->name);
 goto err_duplicate;
 }
 
@@ -1368,10 +1365,9 @@ static int pci_rocker_init(PCIDevice *dev)
 #define ROCKER_IFNAMSIZ 16
 #define MAX_ROCKER_NAME_LEN  (ROCKER_IFNAMSIZ - 1 - 3 - 3)
 if (strlen(r->name) > MAX_ROCKER_NAME_LEN) {
-fprintf(stderr,
-"rocker: name too long; please shorten to at most %d chars\n",
+error_setg(errp,
+"name too long; please shorten to at most %d chars",
 MAX_ROCKER_NAME_LEN);
-err = -EINVAL;
 goto err_name_too_long;
 }
 
@@ -1429,7 +1425,7 @@ static int pci_rocker_init(PCIDevice *dev)
 
 QLIST_INSERT_HEAD(&rockers, r, next);
 
-return 0;
+return;
 
 err_name_too_long:
 err_duplicate:
@@ -1443,7 +1439,6 @@ err_world_type_by_name:
 world_free(r->worlds[i]);
 }
 }
-return err;
 }
 
 static void pci_rocker_uninit(PCIDevice *dev)
@@ -1528,7 +1523,7 @@ static void rocker_class_init(ObjectClass *klass, void 
*data)
 DeviceClass *dc = DEVICE_CLASS(klass);
 PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
 
-k->init = pci_rocker_init;
+k->realize = pci_rocker_realize;
 k->exit = pci_rocker_uninit;
 k->vendor_id = PCI_VENDOR_ID_REDHAT;
 k->device_id = PCI_DEVICE_ID_REDHAT_ROCKER;
-- 
2.9.3

[Qemu-devel] [PATCH v4 2/3] net/rocker: Plug memory leak in pci_rocker_init()

[Mao Zhongyi]

pci_rocker_init() leaks a World when the name more than 9 chars,
then return a negative value directly, doesn't make a correct
cleanup. So add a new goto label to fix it.

Cc: jasow...@redhat.com
Cc: j...@resnulli.us
Cc: f4...@amsat.org
Cc: arm...@redhat.com
Signed-off-by: Mao Zhongyi 
---
 hw/net/rocker/rocker.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
index b2b6dc7..a382a6f 100644
--- a/hw/net/rocker/rocker.c
+++ b/hw/net/rocker/rocker.c
@@ -1371,7 +1371,8 @@ static int pci_rocker_init(PCIDevice *dev)
 fprintf(stderr,
 "rocker: name too long; please shorten to at most %d chars\n",
 MAX_ROCKER_NAME_LEN);
-return -EINVAL;
+err = -EINVAL;
+goto err_name_too_long;
 }
 
 if (memcmp(&r->fp_start_macaddr, &zero, sizeof(zero)) == 0) {
@@ -1430,6 +1431,7 @@ static int pci_rocker_init(PCIDevice *dev)
 
 return 0;
 
+err_name_too_long:
 err_duplicate:
 rocker_msix_uninit(r);
 err_msix_init:
-- 
2.9.3

[Qemu-devel] [PULL 1/7] migration: Fix regression with compression threads

[Juan Quintela]

Compression threads got broken on commit

  commit 247956946651ae0280f7b1ea88bb6237dd01c231
  Author: Juan Quintela 
  Date:   Tue Mar 21 11:45:01 2017 +0100

  ram: reorganize last_sent_block

On do_compress_ram_page() we use a different QEMUFile than the
migration one.  We need to pass it there.  The failure can be seen as:

(qemu) qemu-system-x86_64: Unknown combination of migration flags: 0
qemu-system-x86_64: error while loading state section id 3(ram)
qemu-system-x86_64: load of migration failed: Invalid argument

Signed-off-by: Juan Quintela 
Reviewed-by: Peter Xu 
Tested-by: Peter Xu 
---
 migration/ram.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 293d27c..995d1fc 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -436,20 +436,21 @@ void migrate_compress_threads_create(void)
  * @offset: offset inside the block for the page
  *  in the lower bits, it contains flags
  */
-static size_t save_page_header(RAMState *rs, RAMBlock *block, ram_addr_t 
offset)
+static size_t save_page_header(RAMState *rs, QEMUFile *f,  RAMBlock *block,
+   ram_addr_t offset)
 {
 size_t size, len;
 
 if (block == rs->last_sent_block) {
 offset |= RAM_SAVE_FLAG_CONTINUE;
 }
-qemu_put_be64(rs->f, offset);
+qemu_put_be64(f, offset);
 size = 8;
 
 if (!(offset & RAM_SAVE_FLAG_CONTINUE)) {
 len = strlen(block->idstr);
-qemu_put_byte(rs->f, len);
-qemu_put_buffer(rs->f, (uint8_t *)block->idstr, len);
+qemu_put_byte(f, len);
+qemu_put_buffer(f, (uint8_t *)block->idstr, len);
 size += 1 + len;
 rs->last_sent_block = block;
 }
@@ -571,7 +572,7 @@ static int save_xbzrle_page(RAMState *rs, uint8_t 
**current_data,
 }
 
 /* Send XBZRLE based compressed page */
-bytes_xbzrle = save_page_header(rs, block,
+bytes_xbzrle = save_page_header(rs, rs->f, block,
 offset | RAM_SAVE_FLAG_XBZRLE);
 qemu_put_byte(rs->f, ENCODING_FLAG_XBZRLE);
 qemu_put_be16(rs->f, encoded_len);
@@ -745,7 +746,7 @@ static int save_zero_page(RAMState *rs, RAMBlock *block, 
ram_addr_t offset,
 if (is_zero_range(p, TARGET_PAGE_SIZE)) {
 rs->zero_pages++;
 rs->bytes_transferred +=
-save_page_header(rs, block, offset | RAM_SAVE_FLAG_COMPRESS);
+save_page_header(rs, rs->f, block, offset | 
RAM_SAVE_FLAG_COMPRESS);
 qemu_put_byte(rs->f, 0);
 rs->bytes_transferred += 1;
 pages = 1;
@@ -834,7 +835,7 @@ static int ram_save_page(RAMState *rs, PageSearchStatus 
*pss, bool last_stage)
 
 /* XBZRLE overflow or normal page */
 if (pages == -1) {
-rs->bytes_transferred += save_page_header(rs, block,
+rs->bytes_transferred += save_page_header(rs, rs->f, block,
   offset | RAM_SAVE_FLAG_PAGE);
 if (send_async) {
 qemu_put_buffer_async(rs->f, p, TARGET_PAGE_SIZE,
@@ -860,7 +861,7 @@ static int do_compress_ram_page(QEMUFile *f, RAMBlock 
*block,
 int bytes_sent, blen;
 uint8_t *p = block->host + (offset & TARGET_PAGE_MASK);
 
-bytes_sent = save_page_header(rs, block, offset |
+bytes_sent = save_page_header(rs, f, block, offset |
   RAM_SAVE_FLAG_COMPRESS_PAGE);
 blen = qemu_put_compression_data(f, p, TARGET_PAGE_SIZE,
  migrate_compress_level());
@@ -991,7 +992,7 @@ static int ram_save_compressed_page(RAMState *rs, 
PageSearchStatus *pss,
 pages = save_zero_page(rs, block, offset, p);
 if (pages == -1) {
 /* Make sure the first page is sent out before other pages */
-bytes_xmit = save_page_header(rs, block, offset |
+bytes_xmit = save_page_header(rs, rs->f, block, offset |
   RAM_SAVE_FLAG_COMPRESS_PAGE);
 blen = qemu_put_compression_data(rs->f, p, TARGET_PAGE_SIZE,
  migrate_compress_level());
-- 
2.9.3

[Qemu-devel] [PULL 3/7] ram: Rename RAM_SAVE_FLAG_COMPRESS to RAM_SAVE_FLAG_ZERO

[Juan Quintela]

Reflects better what it does now, and avoid confussions with
RAM_SAVE_FLAG_COMPRESS_PAGE.

Signed-off-by: Juan Quintela 
Reviewed-by: Peter Xu 
---
 migration/ram.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 995d1fc..76c118c 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -48,8 +48,14 @@
 /***/
 /* ram save/restore */
 
+/* RAM_SAVE_FLAG_ZERO used to be named RAM_SAVE_FLAG_COMPRESS, it
+ * worked for pages that where filled with the same char.  We switched
+ * it to only search for the zero value.  And to avoid confusion with
+ * RAM_SSAVE_FLAG_COMPRESS_PAGE just rename it.
+ */
+
 #define RAM_SAVE_FLAG_FULL 0x01 /* Obsolete, not used anymore */
-#define RAM_SAVE_FLAG_COMPRESS 0x02
+#define RAM_SAVE_FLAG_ZERO 0x02
 #define RAM_SAVE_FLAG_MEM_SIZE 0x04
 #define RAM_SAVE_FLAG_PAGE 0x08
 #define RAM_SAVE_FLAG_EOS  0x10
@@ -746,7 +752,7 @@ static int save_zero_page(RAMState *rs, RAMBlock *block, 
ram_addr_t offset,
 if (is_zero_range(p, TARGET_PAGE_SIZE)) {
 rs->zero_pages++;
 rs->bytes_transferred +=
-save_page_header(rs, rs->f, block, offset | 
RAM_SAVE_FLAG_COMPRESS);
+save_page_header(rs, rs->f, block, offset | RAM_SAVE_FLAG_ZERO);
 qemu_put_byte(rs->f, 0);
 rs->bytes_transferred += 1;
 pages = 1;
@@ -2406,7 +2412,7 @@ static int ram_load_postcopy(QEMUFile *f)
 
 trace_ram_load_postcopy_loop((uint64_t)addr, flags);
 place_needed = false;
-if (flags & (RAM_SAVE_FLAG_COMPRESS | RAM_SAVE_FLAG_PAGE)) {
+if (flags & (RAM_SAVE_FLAG_ZERO | RAM_SAVE_FLAG_PAGE)) {
 block = ram_block_from_stream(f, flags);
 
 host = host_from_ram_block_offset(block, addr);
@@ -2453,7 +2459,7 @@ static int ram_load_postcopy(QEMUFile *f)
 last_host = host;
 
 switch (flags & ~RAM_SAVE_FLAG_CONTINUE) {
-case RAM_SAVE_FLAG_COMPRESS:
+case RAM_SAVE_FLAG_ZERO:
 ch = qemu_get_byte(f);
 memset(page_buffer, ch, TARGET_PAGE_SIZE);
 if (ch) {
@@ -2542,7 +2548,7 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
 flags = addr & ~TARGET_PAGE_MASK;
 addr &= TARGET_PAGE_MASK;
 
-if (flags & (RAM_SAVE_FLAG_COMPRESS | RAM_SAVE_FLAG_PAGE |
+if (flags & (RAM_SAVE_FLAG_ZERO | RAM_SAVE_FLAG_PAGE |
  RAM_SAVE_FLAG_COMPRESS_PAGE | RAM_SAVE_FLAG_XBZRLE)) {
 RAMBlock *block = ram_block_from_stream(f, flags);
 
@@ -2604,7 +2610,7 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
 }
 break;
 
-case RAM_SAVE_FLAG_COMPRESS:
+case RAM_SAVE_FLAG_ZERO:
 ch = qemu_get_byte(f);
 ram_handle_compressed(host, ch, TARGET_PAGE_SIZE);
 break;
-- 
2.9.3

[Qemu-devel] [PULL 0/7] Migration pull request

[Juan Quintela]

Hi

This pull request:
- drop block capability patch (now they is being reviewed)
- add following patches that got reviewed:
  * page_cache.c into migration
  * postcopy stuff into postocpy-ram.c
  * check_migratable change

Please apply.

Thanks, Juan.

The following changes since commit cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9:

  block/win32: fix 'ret not initialized' warning (2017-05-16 15:34:18 +0100)

are available in the git repository at:

  git://github.com/juanquintela/qemu.git tags/migration/20170517

for you to fetch changes up to 1bfe5f0586083747f1602931713111673849cd9d:

  migration: Move check_migratable() into qdev.c (2017-05-17 12:04:59 +0200)


migration/next for 20170517


Juan Quintela (7):
  migration: Fix regression with compression threads
  migration: Pass Error ** argument to {save,load}_vmstate
  ram: Rename RAM_SAVE_FLAG_COMPRESS to RAM_SAVE_FLAG_ZERO
  migration: Create migration/blocker.h
  migration: Move page_cache.c to migration/
  migration: Move postcopy stuff to postcopy-ram.c
  migration: Move check_migratable() into qdev.c

 Makefile.objs |  1 -
 block/qcow.c  |  2 +-
 block/vdi.c   |  2 +-
 block/vhdx.c  |  2 +-
 block/vmdk.c  |  2 +-
 block/vpc.c   |  2 +-
 block/vvfat.c |  2 +-
 hmp.c |  9 +++-
 hw/9pfs/9p.c  |  2 +-
 hw/core/qdev.c| 20 +++--
 hw/display/qxl.c  |  2 +-
 hw/display/virtio-gpu.c   |  2 +-
 hw/intc/arm_gic_kvm.c |  2 +-
 hw/intc/arm_gicv3_its_kvm.c   |  2 +-
 hw/intc/arm_gicv3_kvm.c   |  2 +-
 hw/misc/ivshmem.c |  2 +-
 hw/scsi/vhost-scsi.c  |  2 +-
 hw/virtio/vhost.c |  2 +-
 include/migration/blocker.h   | 35 +++
 include/migration/migration.h | 50 --
 include/migration/vmstate.h   |  2 +
 include/sysemu/sysemu.h   |  6 +--
 migration/Makefile.objs   |  2 +-
 migration/migration.c | 34 +--
 page_cache.c => migration/page_cache.c|  0
 {include/migration => migration}/page_cache.h |  0
 migration/postcopy-ram.c  | 18 
 migration/postcopy-ram.h  | 26 
 migration/ram.c   | 35 +--
 migration/savevm.c| 61 +++
 replay/replay-snapshot.c  |  8 +++-
 stubs/migr-blocker.c  |  2 +-
 stubs/vmstate.c   |  5 +--
 target/i386/kvm.c |  2 +-
 tests/Makefile.include|  2 +-
 vl.c  |  4 +-
 36 files changed, 194 insertions(+), 158 deletions(-)
 create mode 100644 include/migration/blocker.h
 rename page_cache.c => migration/page_cache.c (100%)
 rename {include/migration => migration}/page_cache.h (100%)

[Qemu-devel] [PULL 2/7] migration: Pass Error ** argument to {save, load}_vmstate

[Juan Quintela]

This way we use the "normal" way of printing errors for hmp commands.

Signed-off-by: Juan Quintela 
Suggested-by: Paolo Bonzini 
Reviewed-by: Peter Xu 
Reviewed-by: Laurent Vivier 
---
 hmp.c|  9 +++--
 include/sysemu/sysemu.h  |  4 ++--
 migration/savevm.c   | 51 
 replay/replay-snapshot.c |  8 ++--
 vl.c |  4 +++-
 5 files changed, 43 insertions(+), 33 deletions(-)

diff --git a/hmp.c b/hmp.c
index 524e589..b9dd933 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1274,17 +1274,22 @@ void hmp_loadvm(Monitor *mon, const QDict *qdict)
 {
 int saved_vm_running  = runstate_is_running();
 const char *name = qdict_get_str(qdict, "name");
+Error *err = NULL;
 
 vm_stop(RUN_STATE_RESTORE_VM);
 
-if (load_vmstate(name) == 0 && saved_vm_running) {
+if (load_vmstate(name, &err) == 0 && saved_vm_running) {
 vm_start();
 }
+hmp_handle_error(mon, &err);
 }
 
 void hmp_savevm(Monitor *mon, const QDict *qdict)
 {
-save_vmstate(qdict_get_try_str(qdict, "name"));
+Error *err = NULL;
+
+save_vmstate(qdict_get_try_str(qdict, "name"), &err);
+hmp_handle_error(mon, &err);
 }
 
 void hmp_delvm(Monitor *mon, const QDict *qdict)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index be9e22c..282f6bc 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -75,8 +75,8 @@ void qemu_remove_exit_notifier(Notifier *notify);
 void qemu_add_machine_init_done_notifier(Notifier *notify);
 void qemu_remove_machine_init_done_notifier(Notifier *notify);
 
-int save_vmstate(const char *name);
-int load_vmstate(const char *name);
+int save_vmstate(const char *name, Error **errp);
+int load_vmstate(const char *name, Error **errp);
 
 void qemu_announce_self(void);
 
diff --git a/migration/savevm.c b/migration/savevm.c
index 7f66d58..b4f736f 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2069,7 +2069,7 @@ int qemu_loadvm_state(QEMUFile *f)
 return ret;
 }
 
-int save_vmstate(const char *name)
+int save_vmstate(const char *name, Error **errp)
 {
 BlockDriverState *bs, *bs1;
 QEMUSnapshotInfo sn1, *sn = &sn1, old_sn1, *old_sn = &old_sn1;
@@ -2079,29 +2079,27 @@ int save_vmstate(const char *name)
 uint64_t vm_state_size;
 qemu_timeval tv;
 struct tm tm;
-Error *local_err = NULL;
 AioContext *aio_context;
 
 if (!bdrv_all_can_snapshot(&bs)) {
-error_report("Device '%s' is writable but does not support snapshots",
- bdrv_get_device_name(bs));
+error_setg(errp, "Device '%s' is writable but does not support "
+   "snapshots", bdrv_get_device_name(bs));
 return ret;
 }
 
 /* Delete old snapshots of the same name */
 if (name) {
-ret = bdrv_all_delete_snapshot(name, &bs1, &local_err);
+ret = bdrv_all_delete_snapshot(name, &bs1, errp);
 if (ret < 0) {
-error_reportf_err(local_err,
-  "Error while deleting snapshot on device '%s': ",
-  bdrv_get_device_name(bs1));
+error_prepend(errp, "Error while deleting snapshot on device "
+  "'%s': ", bdrv_get_device_name(bs1));
 return ret;
 }
 }
 
 bs = bdrv_all_find_vmstate_bs();
 if (bs == NULL) {
-error_report("No block device can accept snapshots");
+error_setg(errp, "No block device can accept snapshots");
 return ret;
 }
 aio_context = bdrv_get_aio_context(bs);
@@ -2110,7 +2108,7 @@ int save_vmstate(const char *name)
 
 ret = global_state_store();
 if (ret) {
-error_report("Error saving global state");
+error_setg(errp, "Error saving global state");
 return ret;
 }
 vm_stop(RUN_STATE_SAVE_VM);
@@ -2142,21 +2140,20 @@ int save_vmstate(const char *name)
 /* save the VM state */
 f = qemu_fopen_bdrv(bs, 1);
 if (!f) {
-error_report("Could not open VM state file");
+error_setg(errp, "Could not open VM state file");
 goto the_end;
 }
-ret = qemu_savevm_state(f, &local_err);
+ret = qemu_savevm_state(f, errp);
 vm_state_size = qemu_ftell(f);
 qemu_fclose(f);
 if (ret < 0) {
-error_report_err(local_err);
 goto the_end;
 }
 
 ret = bdrv_all_create_snapshot(sn, bs, vm_state_size, &bs);
 if (ret < 0) {
-error_report("Error while creating snapshot on '%s'",
- bdrv_get_device_name(bs));
+error_setg(errp, "Error while creating snapshot on '%s'",
+   bdrv_get_device_name(bs));
 goto the_end;
 }
 
@@ -2229,7 +2226,7 @@ void qmp_xen_load_devices_state(const char *filename, 
Error **errp)
 migration_incoming_state_destroy();
 }
 
-int load_vmstate(const char *name)
+int load_vmstate(const char *name, Error **errp)
 {
 BlockDriverState *bs, *bs_vm_state;
   

[Qemu-devel] [PULL 5/7] migration: Move page_cache.c to migration/

[Juan Quintela]

It is only used by migration, so move it there.

Signed-off-by: Juan Quintela 
Reviewed-by: Dr. David Alan Gilbert 
---
 Makefile.objs | 1 -
 migration/Makefile.objs   | 2 +-
 page_cache.c => migration/page_cache.c| 0
 {include/migration => migration}/page_cache.h | 0
 tests/Makefile.include| 2 +-
 5 files changed, 2 insertions(+), 3 deletions(-)
 rename page_cache.c => migration/page_cache.c (100%)
 rename {include/migration => migration}/page_cache.h (100%)

diff --git a/Makefile.objs b/Makefile.objs
index 6167e7b..2100845 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -49,7 +49,6 @@ common-obj-$(CONFIG_POSIX) += os-posix.o
 common-obj-$(CONFIG_LINUX) += fsdev/
 
 common-obj-y += migration/
-common-obj-y += page_cache.o #aio.o
 
 common-obj-$(CONFIG_SPICE) += spice-qemu-char.o
 
diff --git a/migration/Makefile.objs b/migration/Makefile.objs
index 480dd49..c1920b6 100644
--- a/migration/Makefile.objs
+++ b/migration/Makefile.objs
@@ -1,7 +1,7 @@
 common-obj-y += migration.o socket.o fd.o exec.o
 common-obj-y += tls.o
 common-obj-y += colo-comm.o colo.o colo-failover.o
-common-obj-y += vmstate.o
+common-obj-y += vmstate.o page_cache.o
 common-obj-y += qemu-file.o
 common-obj-y += qemu-file-channel.o
 common-obj-y += xbzrle.o postcopy-ram.o
diff --git a/page_cache.c b/migration/page_cache.c
similarity index 100%
rename from page_cache.c
rename to migration/page_cache.c
diff --git a/include/migration/page_cache.h b/migration/page_cache.h
similarity index 100%
rename from include/migration/page_cache.h
rename to migration/page_cache.h
diff --git a/tests/Makefile.include b/tests/Makefile.include
index 16ff8f3..4277597 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -554,7 +554,7 @@ tests/test-thread-pool$(EXESUF): tests/test-thread-pool.o 
$(test-block-obj-y)
 tests/test-iov$(EXESUF): tests/test-iov.o $(test-util-obj-y)
 tests/test-hbitmap$(EXESUF): tests/test-hbitmap.o $(test-util-obj-y)
 tests/test-x86-cpuid$(EXESUF): tests/test-x86-cpuid.o
-tests/test-xbzrle$(EXESUF): tests/test-xbzrle.o migration/xbzrle.o 
page_cache.o $(test-util-obj-y)
+tests/test-xbzrle$(EXESUF): tests/test-xbzrle.o migration/xbzrle.o 
migration/page_cache.o $(test-util-obj-y)
 tests/test-cutils$(EXESUF): tests/test-cutils.o util/cutils.o
 tests/test-int128$(EXESUF): tests/test-int128.o
 tests/rcutorture$(EXESUF): tests/rcutorture.o $(test-util-obj-y)
-- 
2.9.3

[Qemu-devel] [PULL 4/7] migration: Create migration/blocker.h

[Juan Quintela]

This allows us to remove lots of includes of migration/migration.h

Signed-off-by: Juan Quintela 
Reviewed-by: Peter Xu 
Reviewed-by: Dr. David Alan Gilbert 
---
 block/qcow.c  |  2 +-
 block/vdi.c   |  2 +-
 block/vhdx.c  |  2 +-
 block/vmdk.c  |  2 +-
 block/vpc.c   |  2 +-
 block/vvfat.c |  2 +-
 hw/9pfs/9p.c  |  2 +-
 hw/display/qxl.c  |  2 +-
 hw/display/virtio-gpu.c   |  2 +-
 hw/intc/arm_gic_kvm.c |  2 +-
 hw/intc/arm_gicv3_its_kvm.c   |  2 +-
 hw/intc/arm_gicv3_kvm.c   |  2 +-
 hw/misc/ivshmem.c |  2 +-
 hw/scsi/vhost-scsi.c  |  2 +-
 hw/virtio/vhost.c |  2 +-
 include/migration/blocker.h   | 35 +++
 include/migration/migration.h | 18 --
 migration/migration.c |  1 +
 stubs/migr-blocker.c  |  2 +-
 target/i386/kvm.c |  2 +-
 20 files changed, 53 insertions(+), 35 deletions(-)
 create mode 100644 include/migration/blocker.h

diff --git a/block/qcow.c b/block/qcow.c
index 5d147b9..95ab123 100644
--- a/block/qcow.c
+++ b/block/qcow.c
@@ -32,7 +32,7 @@
 #include 
 #include "qapi/qmp/qerror.h"
 #include "crypto/cipher.h"
-#include "migration/migration.h"
+#include "migration/blocker.h"
 
 /**/
 /* QEMU COW block driver with compression and encryption support */
diff --git a/block/vdi.c b/block/vdi.c
index d12d9cd..79af477 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -55,7 +55,7 @@
 #include "sysemu/block-backend.h"
 #include "qemu/module.h"
 #include "qemu/bswap.h"
-#include "migration/migration.h"
+#include "migration/blocker.h"
 #include "qemu/coroutine.h"
 #include "qemu/cutils.h"
 #include "qemu/uuid.h"
diff --git a/block/vhdx.c b/block/vhdx.c
index e8fe3fb..8b270b5 100644
--- a/block/vhdx.c
+++ b/block/vhdx.c
@@ -24,7 +24,7 @@
 #include "qemu/crc32c.h"
 #include "qemu/bswap.h"
 #include "block/vhdx.h"
-#include "migration/migration.h"
+#include "migration/blocker.h"
 #include "qemu/uuid.h"
 
 /* Options for VHDX creation */
diff --git a/block/vmdk.c b/block/vmdk.c
index c61b9cc..55581b0 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -31,7 +31,7 @@
 #include "qemu/error-report.h"
 #include "qemu/module.h"
 #include "qemu/bswap.h"
-#include "migration/migration.h"
+#include "migration/blocker.h"
 #include "qemu/cutils.h"
 #include 
 
diff --git a/block/vpc.c b/block/vpc.c
index ecfee77..4240ba9 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -28,7 +28,7 @@
 #include "block/block_int.h"
 #include "sysemu/block-backend.h"
 #include "qemu/module.h"
-#include "migration/migration.h"
+#include "migration/blocker.h"
 #include "qemu/bswap.h"
 #include "qemu/uuid.h"
 
diff --git a/block/vvfat.c b/block/vvfat.c
index 9c82371..426ca70 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -28,7 +28,7 @@
 #include "block/block_int.h"
 #include "qemu/module.h"
 #include "qemu/bswap.h"
-#include "migration/migration.h"
+#include "migration/blocker.h"
 #include "qapi/qmp/qint.h"
 #include "qapi/qmp/qbool.h"
 #include "qapi/qmp/qstring.h"
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index c80ba67..ab3e22f 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -23,7 +23,7 @@
 #include "9p-xattr.h"
 #include "coth.h"
 #include "trace.h"
-#include "migration/migration.h"
+#include "migration/blocker.h"
 
 int open_fd_hw;
 int total_open_fd;
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index 4d94cec..ad09bb9 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -26,7 +26,7 @@
 #include "qemu/queue.h"
 #include "qemu/atomic.h"
 #include "sysemu/sysemu.h"
-#include "migration/migration.h"
+#include "migration/blocker.h"
 #include "trace.h"
 
 #include "qxl.h"
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index cfb5dfa..58dc0b2 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -19,7 +19,7 @@
 #include "hw/virtio/virtio.h"
 #include "hw/virtio/virtio-gpu.h"
 #include "hw/virtio/virtio-bus.h"
-#include "migration/migration.h"
+#include "migration/blocker.h"
 #include "qemu/log.h"
 #include "qapi/error.h"
 
diff --git a/hw/intc/arm_gic_kvm.c b/hw/intc/arm_gic_kvm.c
index ec952ec..af5cd36 100644
--- a/hw/intc/arm_gic_kvm.c
+++ b/hw/intc/arm_gic_kvm.c
@@ -24,7 +24,7 @@
 #include "qemu-common.h"
 #include "cpu.h"
 #include "hw/sysbus.h"
-#include "migration/migration.h"
+#include "migration/blocker.h"
 #include "sysemu/kvm.h"
 #include "kvm_arm.h"
 #include "gic_internal.h"
diff --git a/hw/intc/arm_gicv3_its_kvm.c b/hw/intc/arm_gicv3_its_kvm.c
index bd4f3aa..a0441d6 100644
--- a/hw/intc/arm_gicv3_its_kvm.c
+++ b/hw/intc/arm_gicv3_its_kvm.c
@@ -24,7 +24,7 @@
 #include "sysemu/sysemu.h"
 #include "sysemu/kvm.h"
 #include "kvm_arm.h"
-#include "migration/migration.h"
+#include "migration/blocker.h"
 
 #define TYPE_KVM_ARM_ITS "arm-its-kvm"
 #define KVM_ARM_ITS(obj) OBJECT_CHECK(GICv3ITSState, (obj), TY

[Qemu-devel] [PULL 7/7] migration: Move check_migratable() into qdev.c

[Juan Quintela]

The function is only used once, and nothing else in migration knows
about objects.  Create the function vmstate_device_is_migratable() in
savem.c that really do the bit that is related with migration.

Signed-off-by: Juan Quintela 
Reviewed-by: Peter Xu 
---
 hw/core/qdev.c| 20 
 include/migration/migration.h |  6 --
 include/migration/vmstate.h   |  2 ++
 include/sysemu/sysemu.h   |  2 +-
 migration/migration.c | 15 ---
 migration/savevm.c| 10 ++
 stubs/vmstate.c   |  5 ++---
 7 files changed, 31 insertions(+), 29 deletions(-)

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 02b632f..6f1b070 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -37,7 +37,7 @@
 #include "hw/boards.h"
 #include "hw/sysbus.h"
 #include "qapi-event.h"
-#include "migration/migration.h"
+#include "migration/vmstate.h"
 
 bool qdev_hotplug = false;
 static bool qdev_hot_added = false;
@@ -861,6 +861,20 @@ static bool device_get_realized(Object *obj, Error **errp)
 return dev->realized;
 }
 
+static bool check_only_migratable(Object *obj, Error **err)
+{
+DeviceClass *dc = DEVICE_GET_CLASS(obj);
+
+if (!vmstate_check_only_migratable(dc->vmsd)) {
+error_setg(err, "Device %s is not migratable, but "
+   "--only-migratable was specified",
+   object_get_typename(obj));
+return false;
+}
+
+return true;
+}
+
 static void device_set_realized(Object *obj, bool value, Error **errp)
 {
 DeviceState *dev = DEVICE(obj);
@@ -870,7 +884,6 @@ static void device_set_realized(Object *obj, bool value, 
Error **errp)
 Error *local_err = NULL;
 bool unattached_parent = false;
 static int unattached_count;
-int ret;
 
 if (dev->hotplugged && !dc->hotpluggable) {
 error_setg(errp, QERR_DEVICE_NO_HOTPLUG, object_get_typename(obj));
@@ -878,8 +891,7 @@ static void device_set_realized(Object *obj, bool value, 
Error **errp)
 }
 
 if (value && !dev->realized) {
-ret = check_migratable(obj, &local_err);
-if (ret < 0) {
+if (!check_only_migratable(obj, &local_err)) {
 goto fail;
 }
 
diff --git a/include/migration/migration.h b/include/migration/migration.h
index 97e78ba..49ec501 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -22,7 +22,6 @@
 #include "qapi-types.h"
 #include "exec/cpu-common.h"
 #include "qemu/coroutine_int.h"
-#include "qom/object.h"
 
 #define QEMU_VM_FILE_MAGIC   0x5145564d
 #define QEMU_VM_FILE_VERSION_COMPAT  0x0002
@@ -39,9 +38,6 @@
 #define QEMU_VM_COMMAND  0x08
 #define QEMU_VM_SECTION_FOOTER   0x7e
 
-/* for vl.c */
-extern int only_migratable;
-
 struct MigrationParams {
 bool blk;
 bool shared;
@@ -253,8 +249,6 @@ int ram_discard_range(const char *block_name, uint64_t 
start, size_t length);
 int ram_postcopy_incoming_init(MigrationIncomingState *mis);
 void ram_postcopy_migrated_memory_release(MigrationState *ms);
 
-int check_migratable(Object *obj, Error **err);
-
 bool migrate_release_ram(void);
 bool migrate_postcopy_ram(void);
 bool migrate_zero_blocks(void);
diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
index f4bf3f1..8489659 100644
--- a/include/migration/vmstate.h
+++ b/include/migration/vmstate.h
@@ -1067,4 +1067,6 @@ int64_t self_announce_delay(int round)
 
 void dump_vmstate_json_to_file(FILE *out_fp);
 
+bool vmstate_check_only_migratable(const VMStateDescription *vmsd);
+
 #endif
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 282f6bc..83c1ceb 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -15,7 +15,7 @@
 /* vl.c */
 
 extern const char *bios_name;
-
+extern int only_migratable;
 extern const char *qemu_name;
 extern QemuUUID qemu_uuid;
 extern bool qemu_uuid_set;
diff --git a/migration/migration.c b/migration/migration.c
index ed11c1f..0304c01 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1143,21 +1143,6 @@ void migrate_del_blocker(Error *reason)
 migration_blockers = g_slist_remove(migration_blockers, reason);
 }
 
-int check_migratable(Object *obj, Error **err)
-{
-DeviceClass *dc = DEVICE_GET_CLASS(obj);
-if (only_migratable && dc->vmsd) {
-if (dc->vmsd->unmigratable) {
-error_setg(err, "Device %s is not migratable, but "
-   "--only-migratable was specified",
-   object_get_typename(obj));
-return -1;
-}
-}
-
-return 0;
-}
-
 void qmp_migrate_incoming(const char *uri, Error **errp)
 {
 Error *local_err = NULL;
diff --git a/migration/savevm.c b/migration/savevm.c
index b4f736f..f5e8194 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2317,3 +2317,13 @@ void vmstate_register_ram_global(MemoryRegion *mr)
 {
 vmstate_register_ram(mr, NULL);
 }
+
+bool vmstate_check_only_migratable(const VMStat

[Qemu-devel] [PULL 6/7] migration: Move postcopy stuff to postcopy-ram.c

[Juan Quintela]

Yes, we don't have a good place to put that stuff.

Signed-off-by: Juan Quintela 
Reviewed-by: Dr. David Alan Gilbert 
---
 include/migration/migration.h | 26 --
 migration/migration.c | 18 --
 migration/postcopy-ram.c  | 18 ++
 migration/postcopy-ram.h  | 26 ++
 4 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index 47262bd..97e78ba 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -61,28 +61,6 @@ enum mig_rp_message_type {
 
 typedef QLIST_HEAD(, LoadStateEntry) LoadStateEntry_Head;
 
-/* The current postcopy state is read/set by postcopy_state_get/set
- * which update it atomically.
- * The state is updated as postcopy messages are received, and
- * in general only one thread should be writing to the state at any one
- * time, initially the main thread and then the listen thread;
- * Corner cases are where either thread finishes early and/or errors.
- * The state is checked as messages are received to ensure that
- * the source is sending us messages in the correct order.
- * The state is also used by the RAM reception code to know if it
- * has to place pages atomically, and the cleanup code at the end of
- * the main thread to know if it has to delay cleanup until the end
- * of postcopy.
- */
-typedef enum {
-POSTCOPY_INCOMING_NONE = 0,  /* Initial state - no postcopy */
-POSTCOPY_INCOMING_ADVISE,
-POSTCOPY_INCOMING_DISCARD,
-POSTCOPY_INCOMING_LISTENING,
-POSTCOPY_INCOMING_RUNNING,
-POSTCOPY_INCOMING_END
-} PostcopyState;
-
 /* State for the incoming migration */
 struct MigrationIncomingState {
 QEMUFile *from_src_file;
@@ -339,8 +317,4 @@ void global_state_store_running(void);
 void migration_page_queue_free(void);
 int ram_save_queue_pages(const char *rbname, ram_addr_t start, ram_addr_t len);
 uint64_t ram_pagesize_summary(void);
-
-PostcopyState postcopy_state_get(void);
-/* Set the state and return the old state */
-PostcopyState postcopy_state_set(PostcopyState new_state);
 #endif
diff --git a/migration/migration.c b/migration/migration.c
index 5c92851..ed11c1f 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -78,13 +78,6 @@ static NotifierList migration_state_notifiers =
 
 static bool deferred_incoming;
 
-/*
- * Current state of incoming postcopy; note this is not part of
- * MigrationIncomingState since it's state is used during cleanup
- * at the end as MIS is being freed.
- */
-static PostcopyState incoming_postcopy_state;
-
 /* When we add fault tolerance, we could have several
migrations at once.  For now we don't need to add
dynamic creation of migration */
@@ -2098,14 +2091,3 @@ void migrate_fd_connect(MigrationState *s)
 s->migration_thread_running = true;
 }
 
-PostcopyState  postcopy_state_get(void)
-{
-return atomic_mb_read(&incoming_postcopy_state);
-}
-
-/* Set the state and return the old state */
-PostcopyState postcopy_state_set(PostcopyState new_state)
-{
-return atomic_xchg(&incoming_postcopy_state, new_state);
-}
-
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index cdadaf6..a0489f6 100644
--- a/migration/postcopy-ram.c
+++ b/migration/postcopy-ram.c
@@ -784,3 +784,21 @@ void postcopy_discard_send_finish(MigrationState *ms, 
PostcopyDiscardState *pds)
 
 g_free(pds);
 }
+
+/*
+ * Current state of incoming postcopy; note this is not part of
+ * MigrationIncomingState since it's state is used during cleanup
+ * at the end as MIS is being freed.
+ */
+static PostcopyState incoming_postcopy_state;
+
+PostcopyState  postcopy_state_get(void)
+{
+return atomic_mb_read(&incoming_postcopy_state);
+}
+
+/* Set the state and return the old state */
+PostcopyState postcopy_state_set(PostcopyState new_state)
+{
+return atomic_xchg(&incoming_postcopy_state, new_state);
+}
diff --git a/migration/postcopy-ram.h b/migration/postcopy-ram.h
index 4c25f03..52d51e8 100644
--- a/migration/postcopy-ram.h
+++ b/migration/postcopy-ram.h
@@ -81,6 +81,28 @@ int postcopy_place_page(MigrationIncomingState *mis, void 
*host, void *from,
 int postcopy_place_page_zero(MigrationIncomingState *mis, void *host,
  size_t pagesize);
 
+/* The current postcopy state is read/set by postcopy_state_get/set
+ * which update it atomically.
+ * The state is updated as postcopy messages are received, and
+ * in general only one thread should be writing to the state at any one
+ * time, initially the main thread and then the listen thread;
+ * Corner cases are where either thread finishes early and/or errors.
+ * The state is checked as messages are received to ensure that
+ * the source is sending us messages in the correct order.
+ * The state is also used by the RAM reception code to know if it
+ * has to place pages atomically, and the cleanup code at the end of
+ * the main thread to know

Re: [Qemu-devel] [PATCH v2 07/12] dirty-bitmap: Change bdrv_get_dirty_count() to report bytes

[Juan Quintela]

Eric Blake  wrote:
> Thanks to recent cleanups, all callers were scaling a return value
> of sectors into bytes; do the scaling internally instead.
>
> Signed-off-by: Eric Blake 
> Reviewed-by: John Snow 
>

Reviewed-by: Juan Quintela 

Re: [Qemu-devel] [PATCH v2 08/12] dirty-bitmap: Change bdrv_get_dirty() to take bytes

[Juan Quintela]

Eric Blake  wrote:
> Half the callers were already scaling bytes to sectors; the other
> half can eventually be simplified to use byte iteration.  Both
> callers were already using the result as a bool, so make that
> explicit.  Making the change also makes it easier for a future
> dirty-bitmap patch to offload scaling over to the internal hbitmap.
>
> Remember, asking whether a byte is dirty is effectively asking
> whether the entire granularity containing the byte is dirty, since
> we only track dirtiness by granularity.
>
> Signed-off-by: Eric Blake 
> Reviewed-by: John Snow 

Reviewed-by: Juan Quintela 

[Qemu-devel] [PATCH] e1000e: Fix a bug where guest hangs upon migration

[Sameeh Jubran]

The bug was caused by the "receive overrun" (bit #6 of the ICR register) 
interrupt
which would be triggered post migration in a heavy traffic environment. Even 
though the
"receive overrun" bit (#6) is masked out by the IMS register (refer to the log 
below)
the driver still receives an interrupt as the "receive overrun" bit (#6) causes 
the
"Other" - bit #24 of the ICR register - bit to be set as documented below. The 
driver
handles the interrupt and clears the "Other" bit (#24) but doesn't clear the
"receive overrun" bit (#6) which leads to an infinite loop. Apparently the 
Windows
driver expects that the "receive overrun" bit and other ones - documented below 
- to be
cleared when the "Other" bit (#24) is cleared.

So to sum that up:
1. Bit #6 of the ICR register is set by heavy traffic
2. As a results of setting bit #6, bit #24 is set
3. The driver receives an interrupt for bit 24 (it doesn't receieve an 
interrupt for bit #6 as it is masked out by IMS)
4. The driver handles and clears the interrupt of bit #24
5. Bit #6 is still set.
6. 2 happens all over again

The Interrupt Cause Read - ICR register:

The ICR has the "Other" bit - bit #24 - that is set when one or more of the 
following
ICR register's bits are set:

LSC - bit #2, RXO - bit #6, MDAC - bit #9, SRPD - bit #16, ACK - bit #17, MNG - 
bit #18

Log sample of the storm:

27563@1494850819.411877:e1000e_irq_pending_interrupts ICR PENDING: 0x100 
(ICR: 0x815000c2, IMS: 0x1a4)
27563@1494850819.411900:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
0x815000c2, IMS: 0xa4)
27563@1494850819.411915:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
0x815000c2, IMS: 0xa4)
27563@1494850819.412380:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
0x815000c2, IMS: 0xa4)
27563@1494850819.412395:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
0x815000c2, IMS: 0xa4)
27563@1494850819.412436:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
0x815000c2, IMS: 0xa4)
27563@1494850819.412441:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
0x815000c2, IMS: 0xa4)
27563@1494850819.412998:e1000e_irq_pending_interrupts ICR PENDING: 0x100 
(ICR: 0x815000c2, IMS: 0x1a4)

This commit solves:
https://bugzilla.redhat.com/show_bug.cgi?id=1447935
https://bugzilla.redhat.com/show_bug.cgi?id=1449490

Signed-off-by: Sameeh Jubran 
---
 hw/net/e1000e_core.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index 28c5be1..8174b53 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -2454,14 +2454,17 @@ e1000e_set_ics(E1000ECore *core, int index, uint32_t 
val)
 static void
 e1000e_set_icr(E1000ECore *core, int index, uint32_t val)
 {
+uint32_t icr = 0;
 if ((core->mac[ICR] & E1000_ICR_ASSERTED) &&
 (core->mac[CTRL_EXT] & E1000_CTRL_EXT_IAME)) {
 trace_e1000e_irq_icr_process_iame();
 e1000e_clear_ims_bits(core, core->mac[IAM]);
 }
 
-trace_e1000e_irq_icr_write(val, core->mac[ICR], core->mac[ICR] & ~val);
-core->mac[ICR] &= ~val;
+icr = core->mac[ICR] & ~val;
+icr = (val & E1000_ICR_OTHER) ? (icr & ~E1000_ICR_OTHER_CAUSES) : icr;
+trace_e1000e_irq_icr_write(val, core->mac[ICR], icr);
+core->mac[ICR] = icr;
 e1000e_update_interrupt_state(core);
 }
 
-- 
2.8.1.185.gdc0db2c

Re: [Qemu-devel] [RFC PATCH v2 0/8] s390x: Enable virtio-scsi boot from /dev/sgX

[Cornelia Huck]

On Tue, 16 May 2017 15:44:43 +0200
Christian Borntraeger  wrote:

> On 05/10/2017 05:53 PM, Eric Farman wrote:
> > Today, trying to boot a guest from a SCSI LUN on s390x yields the following:
> > 
> >   virtio-blk   = OK
> >   virtio-scsi and /dev/sdX = OK
> >   virtio-scsi and /dev/sgX = FAIL
> > 
> > Example of the failing scenario:
> > 
> >   /usr/bin/qemu-system-s390x ...
> > -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001
> > -drive file=/dev/sg2,if=none,id=drive0,format=raw
> > -device 
> > scsi-generic,bus=scsi0.0,channel=0,scsi-id=0,drive=drive0,id=disk0
> >   LOADPARM=[]
> >   Using virtio-scsi.
> >   Using SCSI scheme.
> >   ..
> >   ! virtio-scsi:read_many: STATUS=02 RSPN=70 KEY=0b CODE=00 QLFR=06, sure !
> > 
> > Why do we care?  Well, libvirt converts a virtio-scsi device from the host
> > SCSI address (host:bus:target:lun) into the associated /dev/sgX device,
> > which means we can't boot from virtio-scsi and have to rely on virtio-blk
> > for this action.
> > 
> > The short version of what happens is the host block device driver rejects 
> > our
> > requests because the transfer lengths are too long for it to satisfy.
> > A virtio-scsi disk connected via scsi-generic is fine as a non-boot device
> > because the guest kernel is able to break up the requests for us.  So we 
> > just
> > need to handle this situation for the boot process.
> > 
> > Patches 1-3 read the max_sectors parameter for the virtio-scsi controller,
> > and break up the READ(10) I/Os into something that the host will accept.
> > If not specified, max_sectors defaults to 65535, but could look like this:
> > 
> >   qemu-system-s390x ...
> > -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001,max_sectors=2048
> > 
> > Patches 4-6 read the max_io_size parameter for the virtio-scsi disk device,
> > and use the minimum of it and the max_sectors from the controller for 
> > breaking
> > up the READ(10) I/Os.  If not specified, max_io_size defaults to 2147483647
> > but could look like this:
> > 
> >   qemu-system-s390x ...
> > -drive file=/dev/sda,if=none,id=drive0,format=raw ...
> > -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,
> > drive=drive0,id=disk0,max_io_size=1048576
> > 
> > In the two examples above, the maximum parameters are equivalent due to the
> > controller parameter measuring 512-byte blocks, and the disk measuring 
> > bytes.
> > 
> > Patch 7 establishes a workable default, in case neither the controller nor
> > the disk have the parameters specified (and thus the overly large defaults
> > are taken), or if they are set to something beyond what we can boot from.
> > 
> > Patch 8 rebuilds the s390-ccw BIOS with this entire patch set.
> > 
> > Changelog:
> > 
> > RFC v2:
> >  - Dropped patch outside the pc-bios/s390-ccw/ tree
> >  - Added Christian's r-b to patch 1 (formerly patch 2)
> >  - Added EVPD Inquiry calls to retrieve Block Limits page if supported
> >  - Added a default if Block Limits page is not supported, or response is
> >still way to big to allow boot
> > RFC v1:
> >  - https://lists.nongnu.org/archive/html/qemu-devel/2017-04/msg05121.html
> > 
> > Eric Farman (8):
> >   pc-bios/s390-ccw: Remove duplicate blk_factor adjustment
> >   pc-bios/s390-ccw: Move SCSI block factor to outer read
> >   pc-bios/s390-ccw: Break up virtio-scsi read into multiples
> >   pc-bios/s390-ccw: Refactor scsi_inquiry function
> >   pc-bios/s390-ccw: Get list of supported VPD pages
> >   pc-bios/s390-ccw: Get Block Limits VPD device data
> >   pc-bios/s390-ccw: Build a reasonable max_sectors limit
> >   pc-bios/s390-ccw.img: rebuild image
> > 
> >  pc-bios/s390-ccw.img   | Bin 26472 -> 26480 bytes
> >  pc-bios/s390-ccw/s390-ccw.h|   7 
> >  pc-bios/s390-ccw/scsi.h|  30 +++
> >  pc-bios/s390-ccw/virtio-scsi.c |  85 
> > +++--
> >  pc-bios/s390-ccw/virtio-scsi.h |   2 +
> >  pc-bios/s390-ccw/virtio.h  |   1 +
> >  6 files changed, 114 insertions(+), 11 deletions(-)
> > 
> 
> Patch set looks good. Conny, can you apply the series?
> 

I had hoped for some comments from folks more familiar with scsi...

Nevertheless, applied to s390-next.

Re: [Qemu-devel] [PATCH] iotests: 147: Don't test inet6 if not available

[Kevin Wolf]

Am 17.05.2017 um 04:13 hat Fam Zheng geschrieben:
> On Fri, 05/05 18:21, Fam Zheng wrote:
> > This is the case in our docker tests, as we use --net=none there. Skip
> > this method.
> 
> Ping. Is this patch okay?

I thought you might want to respond to Dan's comment. If you don't plan
to make the change he suggests, let me know and I'll queue the patch as
it is.

Kevin

Re: [Qemu-devel] [PATCH v2 09/12] dirty-bitmap: Change bdrv_[re]set_dirty_bitmap() to use bytes

[Juan Quintela]

Eric Blake  wrote:
> Some of the callers were already scaling bytes to sectors; others
> can be easily converted to pass byte offsets, all in our shift
> towards a consistent byte interface everywhere.  Making the change
> will also make it easier to write the hold-out callers to use byte
> rather than sectors for their iterations; it also makes it easier
> for a future dirty-bitmap patch to offload scaling over to the
> internal hbitmap.  Although all callers happen to pass
> sector-aligned values, make the internal scaling robust to any
> sub-sector requests.
>
> Signed-off-by: Eric Blake 
> Reviewed-by: John Snow 

Reviewed-by: Juan Quintela 


> +
>  assert(bdrv_dirty_bitmap_enabled(bitmap));
> -hbitmap_set(bitmap->bitmap, cur_sector, nr_sectors);
> +hbitmap_set(bitmap->bitmap, offset >> BDRV_SECTOR_BITS,
> +end_sector - (offset >> BDRV_SECTOR_BITS));

It is just me, or we use:

bytes = sectors * BDRV_SECTOR_SIZE
or
bytes = sectors << BDRV_SECTOR_BITS

and the same from bytes to sectors (no, this patch is consistent,
but just looking at the file )

Later, Juan.

Re: [Qemu-devel] [PATCH v2] virtio: Move memory_listener_unregister to .unrealize

[Fam Zheng]

On Wed, 05/17 02:58, Paolo Bonzini wrote:
> The child property is deleted when bus_unparent calls object_unparent:
> 
> while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) {
> DeviceState *dev = kid->child;
> object_unparent(OBJECT(dev));
> }
> 
> and in turn bus_unparent is called by the VirtIOSCSIPCI's unparent
> callback (device_unparent):
> 
> while (dev->num_child_bus) {
> bus = QLIST_FIRST(&dev->child_bus);
> object_unparent(OBJECT(bus));
> }

OK, sorry for being dumb, these are way over my head. Let me try again:

I count three references before unplug:

a.1) object_property_add_child in virtio_instance_init_common as virtio-backend
a.2) qdev_set_parent_bus in virtio_scsi_pci_realize by virtio-pci-bus
a.3) qbus_set_hotplug_handler in virtio_scsi_device_realize for 

Only two object_unref()'s happen in unplug, respectively:

b.1) object_finalize_child_property, matches a.1)
b.2) bus_remove_child, matches a.2)

Do we need cleanup for a.3) ? The patch below does fix the crash for me.

---

diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index 46a3e3f..fde1b1fe 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -918,6 +918,8 @@ void virtio_scsi_common_unrealize(DeviceState *dev, Error 
**errp)
 
 static void virtio_scsi_device_unrealize(DeviceState *dev, Error **errp)
 {
+VirtIOSCSI *s = VIRTIO_SCSI(dev);
+qbus_set_hotplug_handler(BUS(&s->bus), NULL, &error_abort);
 virtio_scsi_common_unrealize(dev, errp);
 }

Re: [Qemu-devel] [Qemu-block] [RFC PATCH] qemu-io: add drain/undrain cmd

[Stefan Hajnoczi]

On Mon, May 15, 2017 at 12:02:43PM +0200, Peter Lieven wrote:
> I would like to add a feature to Qemu to drain all traffic from a block so 
> that
> I can take external snaphosts without the risk to that in the middle of a 
> write
> operation. Its meant for cases where where QGA freeze/thaw is not available.
> 
> For me its enough to have this through qemu-io, but Kevin asked me to check
> if its not worth to have a stable API for it and present it via QMP/HMP.
> 
> What are your thoughts?

Are the existing snapshot and blockjobs not sufficient for taking
external snapshots?


signature.asc
Description: PGP signature

Re: [Qemu-devel] [Qemu-block] [PATCH] qemu-iotests: Test streaming with missing job ID

[Stefan Hajnoczi]

On Mon, May 15, 2017 at 02:39:40PM +0200, Kevin Wolf wrote:
> This adds a small test for the image streaming error path for failing
> block_job_create(), which would have found the null pointer dereference
> in commit a170a91f.
> 
> Signed-off-by: Kevin Wolf 
> ---
>  tests/qemu-iotests/030 | 4 
>  tests/qemu-iotests/030.out | 4 ++--
>  2 files changed, 6 insertions(+), 2 deletions(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH] iotests: 147: Don't test inet6 if not available

[Fam Zheng]

On Wed, 05/17 13:59, Kevin Wolf wrote:
> Am 17.05.2017 um 04:13 hat Fam Zheng geschrieben:
> > On Fri, 05/05 18:21, Fam Zheng wrote:
> > > This is the case in our docker tests, as we use --net=none there. Skip
> > > this method.
> > 
> > Ping. Is this patch okay?
> 
> I thought you might want to respond to Dan's comment. If you don't plan
> to make the change he suggests, let me know and I'll queue the patch as
> it is.

This check is enough for me and I think it's good to go.

Fam

Re: [Qemu-devel] [PATCH] e1000e: Fix a bug where guest hangs upon migration

[Dmitry Fleytman]

> On 17 May 2017, at 14:46 PM, Sameeh Jubran  wrote:
> 
> The bug was caused by the "receive overrun" (bit #6 of the ICR register) 
> interrupt
> which would be triggered post migration in a heavy traffic environment. Even 
> though the
> "receive overrun" bit (#6) is masked out by the IMS register (refer to the 
> log below)
> the driver still receives an interrupt as the "receive overrun" bit (#6) 
> causes the
> "Other" - bit #24 of the ICR register - bit to be set as documented below. 
> The driver
> handles the interrupt and clears the "Other" bit (#24) but doesn't clear the
> "receive overrun" bit (#6) which leads to an infinite loop. Apparently the 
> Windows
> driver expects that the "receive overrun" bit and other ones - documented 
> below - to be
> cleared when the "Other" bit (#24) is cleared.
> 
> So to sum that up:
> 1. Bit #6 of the ICR register is set by heavy traffic
> 2. As a results of setting bit #6, bit #24 is set
> 3. The driver receives an interrupt for bit 24 (it doesn't receieve an 
> interrupt for bit #6 as it is masked out by IMS)
> 4. The driver handles and clears the interrupt of bit #24
> 5. Bit #6 is still set.
> 6. 2 happens all over again
> 
> The Interrupt Cause Read - ICR register:
> 
> The ICR has the "Other" bit - bit #24 - that is set when one or more of the 
> following
> ICR register's bits are set:
> 
> LSC - bit #2, RXO - bit #6, MDAC - bit #9, SRPD - bit #16, ACK - bit #17, MNG 
> - bit #18
> 
> Log sample of the storm:
> 
> 27563@1494850819.411877:e1000e_irq_pending_interrupts ICR PENDING: 0x100 
> (ICR: 0x815000c2, IMS: 0x1a4)
> 27563@1494850819.411900:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
> 0x815000c2, IMS: 0xa4)
> 27563@1494850819.411915:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
> 0x815000c2, IMS: 0xa4)
> 27563@1494850819.412380:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
> 0x815000c2, IMS: 0xa4)
> 27563@1494850819.412395:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
> 0x815000c2, IMS: 0xa4)
> 27563@1494850819.412436:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
> 0x815000c2, IMS: 0xa4)
> 27563@1494850819.412441:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
> 0x815000c2, IMS: 0xa4)
> 27563@1494850819.412998:e1000e_irq_pending_interrupts ICR PENDING: 0x100 
> (ICR: 0x815000c2, IMS: 0x1a4)
> 
> This commit solves:
> https://bugzilla.redhat.com/show_bug.cgi?id=1447935
> https://bugzilla.redhat.com/show_bug.cgi?id=1449490 
> 


Reviewed-by: Dmitry Fleytman 


> 
> Signed-off-by: Sameeh Jubran 
> ---
> hw/net/e1000e_core.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
> index 28c5be1..8174b53 100644
> --- a/hw/net/e1000e_core.c
> +++ b/hw/net/e1000e_core.c
> @@ -2454,14 +2454,17 @@ e1000e_set_ics(E1000ECore *core, int index, uint32_t 
> val)
> static void
> e1000e_set_icr(E1000ECore *core, int index, uint32_t val)
> {
> +uint32_t icr = 0;
> if ((core->mac[ICR] & E1000_ICR_ASSERTED) &&
> (core->mac[CTRL_EXT] & E1000_CTRL_EXT_IAME)) {
> trace_e1000e_irq_icr_process_iame();
> e1000e_clear_ims_bits(core, core->mac[IAM]);
> }
> 
> -trace_e1000e_irq_icr_write(val, core->mac[ICR], core->mac[ICR] & ~val);
> -core->mac[ICR] &= ~val;
> +icr = core->mac[ICR] & ~val;
> +icr = (val & E1000_ICR_OTHER) ? (icr & ~E1000_ICR_OTHER_CAUSES) : icr;
> +trace_e1000e_irq_icr_write(val, core->mac[ICR], icr);
> +core->mac[ICR] = icr;
> e1000e_update_interrupt_state(core);
> }
> 
> -- 
> 2.8.1.185.gdc0db2c
> 

Re: [Qemu-devel] [PATCH] iotests: 147: Don't test inet6 if not available

[Daniel P. Berrange]

On Wed, May 17, 2017 at 08:10:51PM +0800, Fam Zheng wrote:
> On Wed, 05/17 13:59, Kevin Wolf wrote:
> > Am 17.05.2017 um 04:13 hat Fam Zheng geschrieben:
> > > On Fri, 05/05 18:21, Fam Zheng wrote:
> > > > This is the case in our docker tests, as we use --net=none there. Skip
> > > > this method.
> > > 
> > > Ping. Is this patch okay?
> > 
> > I thought you might want to respond to Dan's comment. If you don't plan
> > to make the change he suggests, let me know and I'll queue the patch as
> > it is.
> 
> This check is enough for me and I think it's good to go.

That's fine with me - i didn't intend my comments to be a blocker. In
general getaddrinfo should only return IPv6 addrs, if IPv6 is actually
usable.

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

Re: [Qemu-devel] [PATCH] iotests: 147: Don't test inet6 if not available

[Fam Zheng]

On Fri, 05/05 11:41, Daniel P. Berrange wrote:
> On Fri, May 05, 2017 at 06:21:53PM +0800, Fam Zheng wrote:
> > This is the case in our docker tests, as we use --net=none there. Skip
> > this method.
> > 
> > Signed-off-by: Fam Zheng 
> > ---
> >  tests/qemu-iotests/147 | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/tests/qemu-iotests/147 b/tests/qemu-iotests/147
> > index 32afea6..db34838 100755
> > --- a/tests/qemu-iotests/147
> > +++ b/tests/qemu-iotests/147
> > @@ -147,6 +147,13 @@ class BuiltinNBD(NBDBlockdevAddBase):
> >  self._server_down()
> >  
> >  def test_inet6(self):
> > +try:
> > +socket.getaddrinfo("::0", "0", socket.AF_INET6,
> > +   socket.SOCK_STREAM, socket.IPPROTO_TCP,
> > +   socket.AI_ADDRCONFIG | socket.AI_CANONNAME)
> > +except socket.gaierror:
> > +# IPv6 not available, skip
> > +return
> 
> FWIW, in test-io-channel-socket.c we call getaddrinfo() and also check
> bind() succeeds (use port==0 to let it select a free port to test bind
> on), before assuming IPv6 is working.

Well it then sounds like we should check bind(port=NBD_PORT). But if we do that,
it looks like a slightly bigger topic, for example a previous run not cleanup?

Let's leave it for now.

Fam

Re: [Qemu-devel] [PATCH] iotests: 147: Don't test inet6 if not available

[Kevin Wolf]

Am 05.05.2017 um 12:21 hat Fam Zheng geschrieben:
> This is the case in our docker tests, as we use --net=none there. Skip
> this method.
> 
> Signed-off-by: Fam Zheng 

Thanks, applied to the block branch.

Kevin

[Qemu-devel] [PATCH v2] ui: egl-headless requires dmabuf support

[Gerd Hoffmann]

Reported-by: Thomas Huth 
Signed-off-by: Gerd Hoffmann 
---
 vl.c | 4 ++--
 ui/Makefile.objs | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/vl.c b/vl.c
index 5c9b40eb1c..2d7aeec186 100644
--- a/vl.c
+++ b/vl.c
@@ -2129,7 +2129,7 @@ static DisplayType select_display(const char *p)
 exit(1);
 }
 } else if (strstart(p, "egl-headless", &opts)) {
-#ifdef CONFIG_OPENGL
+#ifdef CONFIG_OPENGL_DMABUF
 request_opengl = 1;
 display_opengl = 1;
 display = DT_EGL;
@@ -4668,7 +4668,7 @@ int main(int argc, char **argv, char **envp)
 qemu_spice_display_init();
 }
 
-#ifdef CONFIG_OPENGL
+#ifdef CONFIG_OPENGL_DMABUF
 if (display_type == DT_EGL) {
 egl_headless_init();
 }
diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index aac6ae8bef..3369451285 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -33,7 +33,7 @@ common-obj-y += shader.o
 common-obj-y += console-gl.o
 common-obj-y += egl-helpers.o
 common-obj-y += egl-context.o
-common-obj-y += egl-headless.o
+common-obj-$(CONFIG_OPENGL_DMABUF) += egl-headless.o
 ifeq ($(CONFIG_GTK_GL),y)
 common-obj-$(CONFIG_GTK) += gtk-gl-area.o
 else
-- 
2.9.3

Re: [Qemu-devel] [PATCH] gluster: add support for PREALLOC_MODE_FALLOC

[Niels de Vos]

On Tue, May 16, 2017 at 11:42:37AM -0400, Jeff Cody wrote:
> On Mon, May 15, 2017 at 09:11:36PM +0200, Niels de Vos wrote:
> > Add missing support for "preallocation=falloc" to the Gluster block
> > driver. This change bases its logic on that of block/file-posix.c and
> > removed the gluster_supports_zerofill() function in favour of an #ifdef
> > check in an easy to read switch-statement.
> > 
> > Reported-by: Satheesaran Sundaramoorthi 
> > URL: https://bugzilla.redhat.com/1450759
> > Signed-off-by: Niels de Vos 
> > ---
> >  block/gluster.c | 61 
> > +++--
> >  1 file changed, 38 insertions(+), 23 deletions(-)
> > 
> > diff --git a/block/gluster.c b/block/gluster.c
> > index 7c76cd0..566166f 100644
> > --- a/block/gluster.c
> > +++ b/block/gluster.c
> > @@ -965,11 +965,6 @@ static coroutine_fn int 
> > qemu_gluster_co_pwrite_zeroes(BlockDriverState *bs,
> >  return acb.ret;
> >  }
> >  
> > -static inline bool gluster_supports_zerofill(void)
> > -{
> > -return 1;
> > -}
> > -
> >  static inline int qemu_gluster_zerofill(struct glfs_fd *fd, int64_t offset,
> >  int64_t size)
> >  {
> > @@ -977,11 +972,6 @@ static inline int qemu_gluster_zerofill(struct glfs_fd 
> > *fd, int64_t offset,
> >  }
> >  
> >  #else
> > -static inline bool gluster_supports_zerofill(void)
> > -{
> > -return 0;
> > -}
> > -
> >  static inline int qemu_gluster_zerofill(struct glfs_fd *fd, int64_t offset,
> >  int64_t size)
> >  {
> > @@ -996,9 +986,10 @@ static int qemu_gluster_create(const char *filename,
> >  struct glfs *glfs;
> >  struct glfs_fd *fd;
> >  int ret = 0;
> > -int prealloc = 0;
> > +PreallocMode prealloc;
> >  int64_t total_size = 0;
> >  char *tmp = NULL;
> > +Error *local_err = NULL;
> >  
> >  gconf = g_new0(BlockdevOptionsGluster, 1);
> >  gconf->debug = qemu_opt_get_number_del(opts, GLUSTER_OPT_DEBUG,
> > @@ -1026,13 +1017,12 @@ static int qemu_gluster_create(const char *filename,
> >BDRV_SECTOR_SIZE);
> >  
> >  tmp = qemu_opt_get_del(opts, BLOCK_OPT_PREALLOC);
> > -if (!tmp || !strcmp(tmp, "off")) {
> > -prealloc = 0;
> > -} else if (!strcmp(tmp, "full") && gluster_supports_zerofill()) {
> > -prealloc = 1;
> > -} else {
> > -error_setg(errp, "Invalid preallocation mode: '%s'"
> > - " or GlusterFS doesn't support zerofill API", 
> > tmp);
> > +prealloc = qapi_enum_parse(PreallocMode_lookup, tmp,
> > +   PREALLOC_MODE__MAX, PREALLOC_MODE_OFF,
> > +   &local_err);
> > +g_free(tmp);
> > +if (local_err) {
> > +error_propagate(errp, local_err);
> >  ret = -EINVAL;
> >  goto out;
> >  }
> > @@ -1041,21 +1031,46 @@ static int qemu_gluster_create(const char *filename,
> >  O_WRONLY | O_CREAT | O_TRUNC | O_BINARY, S_IRUSR | 
> > S_IWUSR);
> >  if (!fd) {
> >  ret = -errno;
> > -} else {
> > +goto out;
> > +}
> > +
> > +switch (prealloc) {
> > +case PREALLOC_MODE_FALLOC:
> > +if (!glfs_fallocate(fd, 0, 0, total_size)) {
> > +error_setg(errp, "Could not preallocate data for the new 
> > file");
> > +ret = -errno;
> > +}
> 
> Both glfs_fallocate() and glfs_zerofill() are from the same release version,
> right?  I think we need a CONFIG_GLUSTER_FALLOC around the
> PREALLOC_MODE_FALLOC case, just like CONFIG_GLUSTERFS_ZEROFILL.

Yes, both were added at the same GlusterFS release. I'll add the check
in ./configure and #ifdef it.

> > +break;
> > +#ifdef CONFIG_GLUSTERFS_ZEROFILL
> > +case PREALLOC_MODE_FULL:
> >  if (!glfs_ftruncate(fd, total_size)) {
> > -if (prealloc && qemu_gluster_zerofill(fd, 0, total_size)) {
> > +if (qemu_gluster_zerofill(fd, 0, total_size)) {
> 
> If using the CONFIG_GLUSTER_ZEROFILL here, then please get rid of the
> qemu_gluster_zerofill() wrapper, which is in place for the same reason as
> this ifdef.  We can just call glfs_zerofill() here directly.

Right, will do!

> > +error_setg(errp, "Could not zerofill the new file");
> >  ret = -errno;
> >  }
> >  } else {
> > +error_setg(errp, "Could not resize file");
> >  ret = -errno;
> >  }
> > -
> > -if (glfs_close(fd) != 0) {
> > +break;
> > +#endif /* CONFIG_GLUSTERFS_ZEROFILL */
> > +case PREALLOC_MODE_OFF:
> > +if (glfs_ftruncate(fd, total_size) != 0) {
> >  ret = -errno;
> > +error_setg(errp, "Could not resize file");
> >  }
> > +break;
> > +default:
> > +ret = -EINVAL;
> > +error_setg(errp, "Unsupported preallocation mode: %s",
> > +   PreallocMode_lookup[pr

Re: [Qemu-devel] [PATCH v4] qemu-img: Check for backing image if specified during create

[Max Reitz]

On 2017-05-16 10:17, Kevin Wolf wrote:
> Am 15.05.2017 um 21:17 hat Max Reitz geschrieben:
>> On 2017-05-15 20:41, Max Reitz wrote:
>>> On 2017-05-12 21:47, John Snow wrote:


 On 05/12/2017 03:46 PM, Eric Blake wrote:
> On 05/12/2017 01:07 PM, Max Reitz wrote:
>> On 2017-05-11 20:27, John Snow wrote:
>>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786
>>>
>>> Or, rather, force the open of a backing image if one was specified
>>> for creation. Using a similar -unsafe option as rebase, allow qemu-img
>>> to ignore the backing file validation if possible.
>>>
>
>>> +++ b/block.c
>>> @@ -4275,37 +4275,37 @@ void bdrv_img_create(const char *filename, 
>>> const char *fmt,
>>>  // The size for the image must always be specified, with one 
>>> exception:
>>>  // If we are using a backing file, we can obtain the size from 
>>> there
>>>  size = qemu_opt_get_size(opts, BLOCK_OPT_SIZE, 0);
>>> -if (size == -1) {
>>
>> "Hang on, why should this be -1 when the defval is 0? Where does the -1
>> come from?"
>> "..."
>> "Oh, the option exists and is set to -1? Why is that?"
>> "..."
>> "Oh, because this function always sets it itself, and because @img_size
>> is set to (uint64_t)-1."
>
> I had pretty much the same conversation on my v1 review.
> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg01097.html
>
>>
>> First, I won't start with how signed integer overflow is
>> implementation-defined in C because I hope you have thrashed that out
>> with Eric (I hope that "to thrash out" is a good translation for
>> "auskaspern" (lit. "to buffoon out").).
>
> Sounds like a reasonable choice of words, even if I don't speak the
> counterpart language to validate your translation.
>
> (uint64_t)-1 is well-defined in C (so I think we're just fine here). But
> (int64_t)UINT64_MAX is where signed integer overflow does indeed throw
> wrinkles at you.
>>>
>>> We're not really fine because that conversion happens when the result of
>>> qemu_opt_get_size() (a uint64_t) is stored in size (an int64_t).
>>>
> I seem to recall that qemu has chosen to use compiler flags and/or
> assumptions that we are using 2s-complement arithmetic with sane
> behavior (that is, tighter behavior than the bare minimum that C
> requires), because it was easier than auditing our code for strict C
> compliance on border cases of conversions from unsigned to signed that
> trigger undefined behavior.  But again, I don't think it affects this
> patch (where our conversion is only from signed to unsigned, and that is
> well-defined behavior).
>>>
>>> Right. Which is why I said I won't even start on it, but of course I
>>> did. O:-)
>>>
>> Second, well, at least we should put -1 as the default value here, then.
>
> Indeed, now that two reviewers have tripped on it,
> qemu_opt_get_size(,,-1) would be nicer.
>
>>
>> Not strictly your fault or something that you need to fix, but it is
>> just a single line in the vicinity...
>>
>> Let me know if you want to address this, for now I'll leave a
>>
>> Reviewed-by: Max Reitz 
>>
>> here if you don't want to.
>
> I'm okay whether you want to squash that fix into this patch, or whether
> you do it as a separate followup patch.
>

 I had considered the issue separate; but you're welcome to either write
 a patch or squish it into this one, I'm not going to be picky.
>>>
>>> Yep, it is a separate issue, just related. :-)
>>>
>>> But since you and Eric agree, I've squashed it in and thus I'm more than
>>> glad to thank you very much and announce this patch as applied to my
>>> block branch:
>>>
>>> https://github.com/XanClic/qemu/commits/block
>>
>> ...well, so much for that. I'll have to unstage it again because it
>> breaks a bunch of iotests (41 85 96 118 139 141 144 155 156) due to
>> failing to acquire image locks. :-/
>>
>> I suspect this is because the backing file is opened somewhere and
>> trying to open it breaks now with the locking series applied.
> 
> I think we can legitimately set force-shared=on for opening the backing
> file when testing whether the file exists.

For testing whether the file exists, probably. I wouldn't call it
legitimately because I don't like making that the default at all, but it
should work.

But then we have to differentiate between testing whether the file
exists and opening it to read its size; I'm even more wary regarding the
latter.

All in all, I've stated my opinion on this matter on IRC: I don't know
how much we need this patch. It's nice to have, it's convenient to know
you have mistyped the backing filename before you try to use the image
in qemu, but it's not critical. I don't consider the current behavior a
bug per-se, it's just counterintuitive behavior (

[Qemu-devel] [PATCH v2] .gdbinit: load QEMU sub-commands when gdb starts

[Stefan Hajnoczi]

The scripts/qemu-gdb.py file is not easily discoverable.  Add a .gdbinit
file so GDB either loads qemu-gdb.py automatically or prints a message
informing the user how to enable them (some systems disable ./.gdbinit
loading for security reasons).

Symlink .gdbinit and the scripts directory in order to make out-of-tree
builds work.  The scripts directory is used to find the qemu-gdb.py file
specified by a relative path in .gdbinit.

Suggested-by: Eric Blake 
Signed-off-by: Stefan Hajnoczi 
---
v2:
 * Support out-of-tree builds [Daniel, Markus]

 configure | 1 +
 .gdbinit  | 8 
 2 files changed, 9 insertions(+)
 create mode 100644 .gdbinit

diff --git a/configure b/configure
index 57b5ae6..04f7272 100755
--- a/configure
+++ b/configure
@@ -6382,6 +6382,7 @@ FILES="$FILES pc-bios/spapr-rtas/Makefile"
 FILES="$FILES pc-bios/s390-ccw/Makefile"
 FILES="$FILES roms/seabios/Makefile roms/vgabios/Makefile"
 FILES="$FILES pc-bios/qemu-icon.bmp"
+FILES="$FILES .gdbinit scripts" # scripts needed by relative path in .gdbinit
 for bios_file in \
 $source_path/pc-bios/*.bin \
 $source_path/pc-bios/*.lid \
diff --git a/.gdbinit b/.gdbinit
new file mode 100644
index 000..9d322fc
--- /dev/null
+++ b/.gdbinit
@@ -0,0 +1,8 @@
+# GDB may have ./.gdbinit loading disabled by default.  In that case you can
+# follow the instructions it prints.  They boil down to adding the following to
+# your home directory's ~/.gdbinit file:
+#
+#   add-auto-load-safe-path /path/to/qemu/.gdbinit
+
+# Load QEMU-specific sub-commands and settings
+source scripts/qemu-gdb.py
-- 
2.9.3

Re: [Qemu-devel] [PATCH] oslib: strip trailing '\n' from error_setg() string argument

[Stefan Hajnoczi]

On Mon, May 15, 2017 at 09:11:49PM -0300, Philippe Mathieu-Daudé wrote:
> spotted by Coccinelle script scripts/coccinelle/err-bad-newline.cocci
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  util/oslib-posix.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Please send multi-patch series with a cover letter and proper patch
numbering ([PATCH 0/2], [PATCH 1/2], [PATCH 2/2]).  git-format-patch and
git-send-email normally do this.  It's important so that patch
management tools and continuous integration systems can track your
patches.

Thanks, applied to my block tree:
https://github.com/stefanha/qemu/commits/block

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v2] virtio: Move memory_listener_unregister to .unrealize

[Paolo Bonzini]

On 17/05/2017 14:00, Fam Zheng wrote:
> On Wed, 05/17 02:58, Paolo Bonzini wrote:
>> The child property is deleted when bus_unparent calls object_unparent:
>>
>> while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) {
>> DeviceState *dev = kid->child;
>> object_unparent(OBJECT(dev));
>> }
>>
>> and in turn bus_unparent is called by the VirtIOSCSIPCI's unparent
>> callback (device_unparent):
>>
>> while (dev->num_child_bus) {
>> bus = QLIST_FIRST(&dev->child_bus);
>> object_unparent(OBJECT(bus));
>> }
> 
> OK, sorry for being dumb, these are way over my head. Let me try again:
> 
> I count three references before unplug:
> 
> a.1) object_property_add_child in virtio_instance_init_common as 
> virtio-backend
> a.2) qdev_set_parent_bus in virtio_scsi_pci_realize by virtio-pci-bus
> a.3) qbus_set_hotplug_handler in virtio_scsi_device_realize for 
> 
> Only two object_unref()'s happen in unplug, respectively:
> 
> b.1) object_finalize_child_property, matches a.1)
> b.2) bus_remove_child, matches a.2)
> 
> Do we need cleanup for a.3) ? The patch below does fix the crash for me.

Yes, good catch.  Either there, or in bus_unparent.

Paolo

Re: [Qemu-devel] [Qemu-block] [PULL 0/8] Block patches for curl

[Stefan Hajnoczi]

On Tue, May 16, 2017 at 11:54:12AM -0400, Jeff Cody wrote:
> The following changes since commit 3a8760664d5c1a1a93c9012bdb8ac07ab8fd4b0d:
> 
>   Merge tag 'tracing-pull-request' into staging (2017-05-12 10:39:35 -0400)
> 
> are available in the git repository at:
> 
>   git://github.com/codyprime/qemu-kvm-jtc.git tags/block-pull-request
> 
> for you to fetch changes up to 2bb5c936c5827e1d831002f7a7517cb8c2c2201d:
> 
>   curl: do not do aio_poll when waiting for a free CURLState (2017-05-16 
> 10:34:50 -0400)
> 
> 
> Curl patches
> 
> 
> Paolo Bonzini (7):
>   curl: strengthen assertion in curl_clean_state
>   curl: never invoke callbacks with s->mutex held
>   curl: avoid recursive locking of BDRVCURLState mutex
>   curl: split curl_find_state/curl_init_state
>   curl: convert CURLAIOCB to byte values
>   curl: convert readv to coroutines
>   curl: do not do aio_poll when waiting for a free CURLState
> 
> Peter Krempa (1):
>   block: curl: Allow passing cookies via QCryptoSecret
> 
>  block/curl.c | 239 
> ++-
>  qapi/block-core.json |  12 ++-
>  2 files changed, 153 insertions(+), 98 deletions(-)
> 
> -- 
> 2.9.3
> 
> 

Thanks, applied to my staging tree:
https://github.com/stefanha/qemu/commits/staging

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH] nvme: Add support for Controller Memory Buffers

[Kevin Wolf]

Am 17.05.2017 um 04:22 hat Stephen  Bates geschrieben:
> > Awesome, this looks great!
> >
> > Acked-by: Keith Busch 
> 
> Thanks Keith!
> 
> I still seem to be having issues getting my patches onto the qemu-*
> mailing lists. Does anyone have any idea how I go about rectifying
> that?

This mail seems to have made it to the list, but the patch hasn't.
Looking at the headers, you don't seem to use the same server for
your normal mail client and git send-email. Maybe it's related to this?

Anyway, thanks, applied to the block branch.

Kevin

Re: [Qemu-devel] [PULL 0/4] please pull xen-20170516-tag

[Stefan Hajnoczi]

On Tue, May 16, 2017 at 12:19:26PM -0700, Stefano Stabellini wrote:
> The following changes since commit cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9:
> 
>   block/win32: fix 'ret not initialized' warning (2017-05-16 15:34:18 +0100)
> 
> are available in the git repository at:
> 
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170516-tag
> 
> for you to fetch changes up to 01cd90b641e1aed40cf13a577e6a737af94d55e7:
> 
>   xen: call qemu_set_cloexec instead of fcntl (2017-05-16 11:51:25 -0700)
> 
> 
> Xen 2017/05/16
> 
> 
> Anthony PERARD (1):
>   configure: Remove -lxencall for Xen detection
> 
> Stefano Stabellini (3):
>   xen/mapcache: store dma information in revmapcache entries for debugging
>   xen/9pfs: fix two resource leaks on error paths, discovered by Coverity
>   xen: call qemu_set_cloexec instead of fcntl
> 
>  configure |  2 +-
>  exec.c|  8 
>  hw/9pfs/xen-9p-backend.c  |  4 +++-
>  hw/i386/xen/xen-mapcache.c| 15 ++-
>  hw/xen/xen_backend.c  |  2 +-
>  include/sysemu/xen-mapcache.h |  5 +++--
>  6 files changed, 22 insertions(+), 14 deletions(-)

Thanks, applied to my staging tree:
https://github.com/stefanha/qemu/commits/staging

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request

[Halil Pasic]

On 05/17/2017 01:10 PM, Cornelia Huck wrote:
> On Wed, 17 May 2017 12:33:20 +0200
> Halil Pasic  wrote:
> 
>> On 05/17/2017 12:13 PM, Gonglei (Arei) wrote:

 On 05/17/2017 11:12 AM, Gonglei (Arei) wrote:
 By the way, I'm having a hard time understing how is the requirement
 form

>>
 http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-260
 004
 (2.4.4 Message Framing) satisfied by this code. Could you explain this
 to me please?

>>> Sorry for my bad English,
>>> I don't know which normative formulation the code violates?
>> I'm not sure it's actually violated, but I'm concerned about the 
>> following
>> normative statement: "The device MUST NOT make assumptions about the
>> particular
>> arrangement of descriptors. The device MAY have a reasonable limit of
>> descriptors it will allow in a chain."
>>
>> Please also read the explanatory part I've linked, because the normative
>> statement is pretty abstract.
>>
>> In my understanding, the spec says, that e.g. the virti-crypto device
>> should not fail if a single request is split up into let's say two chunks
>> and transmitted by the means of two top level descriptors.
>>
>> Do you agree with my reading of the spec?
>>
> Yes, I agree. But what's the relationship about the request here?
> We don't assume the request have to use one desc entity, it can
> use scatter-gather list for one request header.
> The device can cover the situation in the QEMU.
>
>> What does the virtio-crypto device do if it encounters such a situation?
>>
> This isn't a problem. Pls see blow code segment:
>
> virtio_crypto_handle_request()
> {...
> if (unlikely(iov_to_buf(out_iov, out_num, 0, &req, sizeof(req))
> != sizeof(req))) {
> virtio_error(vdev, "virtio-crypto request outhdr too short");
> return -1;
> }
> iov_discard_front(&out_iov, &out_num, sizeof(req));
> ...
>

 Thats exactly what worries me. I see a call to virtio_error there...


 void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice *vdev, const char *fmt, 
 ...)
 {
 va_list ap;

 va_start(ap, fmt);
 error_vreport(fmt, ap);
 va_end(ap);

 vdev->broken = true;

 if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
 virtio_set_status(vdev, vdev->status |
 VIRTIO_CONFIG_S_NEEDS_RESET);
 virtio_notify_config(vdev);
 }
 }

 This however seems to make the device 'broken'. Or am I missing something?

>>> Yes, if the parse process failed, the device will broke. 
>>> But This is a exception scenario IMHO, which is the same situation
>>> with other virtio devices. 
>>
>> I know that virtio-blk does the same. I'm not sure my reading of the
>> spec is correct. Maybe Stefan, Michael or Connie can clarify this
>> for us!
> 
> The spec says for NEEDS_RESET:
> 
> "Indicates that the device has experienced an error from which it can't
> recover."
> 
> For me, this means:
> - If this is something that might happen in the normal course of events
> and there's a good recovery path, just recover.
> - Else, use virtio_error() and require the driver to recover via reset.
> 
> If the driver is sending requests in an unexpected format, I'd use
> virtio_error(). The format needs to be properly described, though.
> 


All-clear, my bad. After re-reading the spec and virtio_pop I have
realized that virtio_pop pops full descriptor chains. These however
correspond to single requests. Thus at the given point the full request
has to be placed into the queue. Sorry!

>>
>> By the way for virtio-blk the current handling was introduced by
>> commit 20ea686a0 (by Greg Kurz), but before we were failing even
>> harder.
>>
>> Regards,
>> Halil
>>
>>>
>>> Stefan introduced the virtio_error().
>>>
>>> Thanks,
>>> -Gonglei
>>>
> 
> 

Re: [Qemu-devel] [RESEND PATCH] virtio: allow broken device to notify guest

[Stefan Hajnoczi]

On Wed, May 17, 2017 at 10:17:51AM +0200, Greg Kurz wrote:
> According to section 2.1.2 of the virtio-1 specification:
> 
> "The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state that
> a reset is needed. If DRIVER_OK is set, after it sets DEVICE_NEEDS_RESET,
> the device MUST send a device configuration change notification to the
> driver."
> 
> Commit "f5ed36635d8f virtio: stop virtqueue processing if device is broken"
> introduced a virtio_error() call that just does that:
> 
> - internally mark the device as broken
> - set the DEVICE_NEEDS_RESET bit in the status
> - send a configuration change notification
> 
> Unfortunately, virtio_notify_vector(), called by virtio_notify_config(),
> returns right away when the device is marked as broken and the notification
> isn't sent in this case.
> 
> The spec doesn't say whether a broken device can send notifications
> in other situations or not. But since the driver isn't supposed to do
> anything but to reset the device, it makes sense to keep the check in
> virtio_notify_config().
> 
> Marking the device as broken AFTER the configuration change notification was
> sent is enough to fix the issue.
> 
> Signed-off-by: Greg Kurz 
> Reviewed-by: Cornelia Huck 
> ---
>  hw/virtio/virtio.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Re-sending this patch with Cornelia's Reviewed-by and Cc'ing qemu-stable
> since this is a spec violation, as suggested in:
> 
> Message-ID: <20170427183237-mutt-send-email-...@kernel.org>
> 
> Cheers,
> 
> --
> Greg

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH] qemu-iotests: Test streaming with missing job ID

[Jeff Cody]

On Mon, May 15, 2017 at 02:39:40PM +0200, Kevin Wolf wrote:
> This adds a small test for the image streaming error path for failing
> block_job_create(), which would have found the null pointer dereference
> in commit a170a91f.
> 
> Signed-off-by: Kevin Wolf 
> ---

Reviewed-by: Jeff Cody 


>  tests/qemu-iotests/030 | 4 
>  tests/qemu-iotests/030.out | 4 ++--
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
> index e00c11b..feee861 100755
> --- a/tests/qemu-iotests/030
> +++ b/tests/qemu-iotests/030
> @@ -147,6 +147,10 @@ class TestSingleDrive(iotests.QMPTestCase):
>  result = self.vm.qmp('block-stream', device='nonexistent')
>  self.assert_qmp(result, 'error/class', 'GenericError')
>  
> +def test_job_id_missing(self):
> +result = self.vm.qmp('block-stream', device='mid')
> +self.assert_qmp(result, 'error/class', 'GenericError')
> +
>  
>  class TestParallelOps(iotests.QMPTestCase):
>  num_ops = 4 # Number of parallel block-stream operations
> diff --git a/tests/qemu-iotests/030.out b/tests/qemu-iotests/030.out
> index 84bfd63..391c857 100644
> --- a/tests/qemu-iotests/030.out
> +++ b/tests/qemu-iotests/030.out
> @@ -1,5 +1,5 @@
> -..
> +...
>  --
> -Ran 22 tests
> +Ran 23 tests
>  
>  OK
> -- 
> 1.8.3.1
> 
> 

[Qemu-devel] [PULL 00/22] x86 and machine queue, 2017-05-17

[Eduardo Habkost]

The following changes since commit 599c9cb641cc484876d5bb92189d09ba27bbfdfd:

  Merge remote-tracking branch 'sstabellini/tags/xen-20170516-tag' into staging 
(2017-05-17 14:03:35 +0100)

are available in the git repository at:

  git://github.com/ehabkost/qemu.git tags/x86-and-machine-pull-request

for you to fetch changes up to 17e8f541263fd771aef58e9818a2060b81904c3f:

  tests: Add [+-]feature and feature=on|off test cases (2017-05-17 10:37:15 
-0300)


x86 and machine queue, 2017-05-17



Eduardo Habkost (22):
  qdev: Replace cannot_instantiate_with_device_add_yet with
!user_creatable
  sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICE
  xen-backend: Remove FIXME comment about user_creatable flag
  iommu: Remove FIXME comment about user_creatable=true
  fdc: Remove user_creatable flag from sysbus-fdc & SUNW,fdtwo
  pflash_cfi01: Remove user_creatable flag
  kvmclock: Remove user_creatable flag
  ioapic: Remove user_creatable flag
  kvmvapic: Remove user_creatable flag
  sysbus-ahci: Remove user_creatable flag
  allwinner-ahci: Remove user_creatable flag
  isabus-bridge: Remove user_creatable flag
  unimplemented-device: Remove user_creatable flag
  fw_cfg: Remove user_creatable flag
  esp: Remove user_creatable flag
  generic-sdhci: Remove user_creatable flag
  hpet: Remove user_creatable flag
  sysbus-ohci: Remove user_creatable flag
  virtio-mmio: Remove user_creatable flag
  xen-sysdev: Remove user_creatable flag
  s390-pcibus: No need to set user_creatable=false explicitly
  tests: Add [+-]feature and feature=on|off test cases

 include/hw/qdev-core.h  |   9 +--
 include/hw/qdev-properties.h|   4 +-
 hw/acpi/piix4.c |   2 +-
 hw/arm/spitz.c  |   2 +-
 hw/audio/marvell_88w8618.c  |   2 +-
 hw/audio/pcspk.c|   2 +-
 hw/core/or-irq.c|   2 +-
 hw/core/qdev.c  |   1 +
 hw/core/register.c  |   2 +-
 hw/core/sysbus.c|  11 
 hw/dma/i8257.c  |   2 +-
 hw/dma/sparc32_dma.c|   2 +-
 hw/gpio/omap_gpio.c |   4 +-
 hw/i2c/omap_i2c.c   |   2 +-
 hw/i2c/smbus_eeprom.c   |   2 +-
 hw/i2c/smbus_ich9.c |   2 +-
 hw/i386/amd_iommu.c |   2 +
 hw/i386/intel_iommu.c   |   2 +
 hw/i386/pc.c|   2 +-
 hw/input/vmmouse.c  |   2 +-
 hw/intc/apic_common.c   |   2 +-
 hw/intc/etraxfs_pic.c   |   2 +-
 hw/intc/grlib_irqmp.c   |   2 +-
 hw/intc/i8259_common.c  |   2 +-
 hw/intc/nios2_iic.c |   2 +-
 hw/intc/omap_intc.c |   4 +-
 hw/isa/lpc_ich9.c   |   2 +-
 hw/isa/piix4.c  |   2 +-
 hw/isa/vt82c686.c   |   2 +-
 hw/mips/gt64xxx_pci.c   |   2 +-
 hw/misc/vmport.c|   2 +-
 hw/net/dp8393x.c|   2 +-
 hw/net/etraxfs_eth.c|   2 +-
 hw/net/fsl_etsec/etsec.c|   2 +
 hw/net/lance.c  |   2 +-
 hw/pci-bridge/dec.c |   2 +-
 hw/pci-bridge/pci_expander_bridge.c |   2 +-
 hw/pci-host/apb.c   |   2 +-
 hw/pci-host/bonito.c|   2 +-
 hw/pci-host/gpex.c  |   2 +-
 hw/pci-host/grackle.c   |   2 +-
 hw/pci-host/piix.c  |   6 +-
 hw/pci-host/ppce500.c   |   2 +-
 hw/pci-host/prep.c  |   2 +-
 hw/pci-host/q35.c   |   4 +-
 hw/pci-host/uninorth.c  |   8 +--
 hw/pci-host/versatile.c |   2 +-
 hw/pci-host/xilinx-pcie.c   |   2 +-
 hw/ppc/ppc4xx_pci.c |   2 +-
 hw/ppc/spapr_drc.c  |   2 +-
 hw/ppc/spapr_pci.c  |   2 +
 hw/s390x/s390-pci-bus.c |   1 -
 hw/sd/milkymist-memcard.c   |   2 +-
 hw/sd/pl181.c   |   2 +-
 hw/sh4/sh_pci.c |   2 +-
 hw/timer/i8254_common.c |   2 +-
 hw/timer/mc146818rtc.c  |   2 +-
 hw/vfio/amd-xgbe.c  |   2 +
 hw/vfio/calxeda-xgmac.c |   2 +
 hw/xen/xen_backend.c|   2 +
 monitor.c   |   2 +-
 qdev-monitor.c  |   6 +-
 qom/cpu.c   |   2 +-
 target/i386/cpu.c   |   2 +-
 tests/test-x86-cpuid-compat.c   | 111 
 65 files changed, 206 insertions(+), 69 deletions(-)

-- 
2.11.0.259.g40922b1

[Qemu-devel] [PULL 01/22] qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable

[Eduardo Habkost]

cannot_instantiate_with_device_add_yet was introduced by commit
efec3dd631d94160288392721a5f9c39e50fb2bc to replace no_user. It was
supposed to be a temporary measure.

When it was introduced, we had 54
cannot_instantiate_with_device_add_yet=true lines in the code.
Today (3 years later) this number has not shrunk: we now have
57 cannot_instantiate_with_device_add_yet=true lines. I think it
is safe to say it is not a temporary measure, and we won't see
the flag go away soon.

Instead of a long field name that misleads people to believe it
is temporary, replace it a shorter and less misleading field:
user_creatable.

Except for code comments, changes were generated using the
following Coccinelle patch:

  @@
  expression DC;
  @@
  (
  -DC->cannot_instantiate_with_device_add_yet = false;
  +DC->user_creatable = true;
  |
  -DC->cannot_instantiate_with_device_add_yet = true;
  +DC->user_creatable = false;
  )

  @@
  typedef ObjectClass;
  expression dc;
  identifier class, data;
  @@
   static void device_class_init(ObjectClass *class, void *data)
   {
   ...
   dc->hotpluggable = true;
  +dc->user_creatable = true;
   ...
   }

  @@
  @@
   struct DeviceClass {
   ...
  -bool cannot_instantiate_with_device_add_yet;
  +bool user_creatable;
   ...
  }

  @@
  expression DC;
  @@
  (
  -!DC->cannot_instantiate_with_device_add_yet
  +DC->user_creatable
  |
  -DC->cannot_instantiate_with_device_add_yet
  +!DC->user_creatable
  )

Cc: Alistair Francis 
Cc: Laszlo Ersek 
Cc: Marcel Apfelbaum 
Cc: Markus Armbruster 
Cc: Peter Maydell 
Cc: Thomas Huth 
Acked-by: Alistair Francis 
Reviewed-by: Thomas Huth 
Reviewed-by: Marcel Apfelbaum 
Acked-by: Marcel Apfelbaum 
Signed-off-by: Eduardo Habkost 
Message-Id: <20170503203604.31462-2-ehabk...@redhat.com>
[ehabkost: kept "TODO remove once we're there" comment]
Reviewed-by: Markus Armbruster 
Signed-off-by: Eduardo Habkost 
---
 include/hw/qdev-core.h  | 9 +
 include/hw/qdev-properties.h| 4 ++--
 hw/acpi/piix4.c | 2 +-
 hw/arm/spitz.c  | 2 +-
 hw/audio/marvell_88w8618.c  | 2 +-
 hw/audio/pcspk.c| 2 +-
 hw/core/or-irq.c| 2 +-
 hw/core/qdev.c  | 1 +
 hw/core/register.c  | 2 +-
 hw/dma/i8257.c  | 2 +-
 hw/dma/sparc32_dma.c| 2 +-
 hw/gpio/omap_gpio.c | 4 ++--
 hw/i2c/omap_i2c.c   | 2 +-
 hw/i2c/smbus_eeprom.c   | 2 +-
 hw/i2c/smbus_ich9.c | 2 +-
 hw/i386/pc.c| 2 +-
 hw/input/vmmouse.c  | 2 +-
 hw/intc/apic_common.c   | 2 +-
 hw/intc/etraxfs_pic.c   | 2 +-
 hw/intc/grlib_irqmp.c   | 2 +-
 hw/intc/i8259_common.c  | 2 +-
 hw/intc/nios2_iic.c | 2 +-
 hw/intc/omap_intc.c | 4 ++--
 hw/isa/lpc_ich9.c   | 2 +-
 hw/isa/piix4.c  | 2 +-
 hw/isa/vt82c686.c   | 2 +-
 hw/mips/gt64xxx_pci.c   | 2 +-
 hw/misc/vmport.c| 2 +-
 hw/net/dp8393x.c| 2 +-
 hw/net/etraxfs_eth.c| 2 +-
 hw/net/lance.c  | 2 +-
 hw/pci-bridge/dec.c | 2 +-
 hw/pci-bridge/pci_expander_bridge.c | 2 +-
 hw/pci-host/apb.c   | 2 +-
 hw/pci-host/bonito.c| 2 +-
 hw/pci-host/gpex.c  | 2 +-
 hw/pci-host/grackle.c   | 2 +-
 hw/pci-host/piix.c  | 6 +++---
 hw/pci-host/ppce500.c   | 2 +-
 hw/pci-host/prep.c  | 2 +-
 hw/pci-host/q35.c   | 4 ++--
 hw/pci-host/uninorth.c  | 8 
 hw/pci-host/versatile.c | 2 +-
 hw/pci-host/xilinx-pcie.c   | 2 +-
 hw/ppc/ppc4xx_pci.c | 2 +-
 hw/ppc/spapr_drc.c  | 2 +-
 hw/s390x/s390-pci-bus.c | 2 +-
 hw/sd/milkymist-memcard.c   | 2 +-
 hw/sd/pl181.c   | 2 +-
 hw/sh4/sh_pci.c | 2 +-
 hw/timer/i8254_common.c | 2 +-
 hw/timer/mc146818rtc.c  | 2 +-
 monitor.c   | 2 +-
 qdev-monitor.c  | 6 +++---
 qom/cpu.c   | 2 +-
 target/i386/cpu.c   | 2 +-
 56 files changed, 71 insertions(+), 69 deletions(-)

diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 4bf86b0ad8..e69489ec6c 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -103,16 +103,17 @@ typedef struct DeviceClass {
 Property *props;
 
 /*
- * Shall we hide this device model from -device / device_add?
+ * Can this device be instantiated with -device / device_add?
  * All devices should support instantiation with device_add, and
  * this flag should not exist.  But we're not there, yet.  Some
  * devices fail to instantiate with crypti

[Qemu-devel] [PULL 10/22] sysbus-ahci: Remove user_creatable flag

[Eduardo Habkost]

The sysbus-ahci devices are supposed to be created and wired by
code from other devices, like calxeda_init() and
xlnx_zynqmp_realize(), and won't work with -device. Remove the
user_creatable flag from the device class.

Cc: John Snow 
Cc: qemu-bl...@nongnu.org
Cc: Rob Herring 
Cc: Peter Maydell 
Cc: Alistair Francis 
Cc: "Edgar E. Iglesias" 
Cc: Marcel Apfelbaum 
Reviewed-by: Alistair Francis 
Acked-by: John Snow 
Acked-by: Marcel Apfelbaum 
Signed-off-by: Eduardo Habkost 
Message-Id: <20170503203604.31462-11-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 hw/ide/ahci.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 7f10cda354..2ea1a282ef 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -1721,11 +1721,6 @@ static void sysbus_ahci_class_init(ObjectClass *klass, 
void *data)
 dc->props = sysbus_ahci_properties;
 dc->reset = sysbus_ahci_reset;
 set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
-/*
- * FIXME: Set only because we are not sure yet if this device
- * will be outside the q35 sysbus whitelist.
- */
-dc->user_creatable = true;
 }
 
 static const TypeInfo sysbus_ahci_info = {
-- 
2.11.0.259.g40922b1

Re: [Qemu-devel] [PATCH v2 09/12] dirty-bitmap: Change bdrv_[re]set_dirty_bitmap() to use bytes

[Eric Blake]

On 05/17/2017 06:59 AM, Juan Quintela wrote:
> Eric Blake  wrote:
>> Some of the callers were already scaling bytes to sectors; others
>> can be easily converted to pass byte offsets, all in our shift
>> towards a consistent byte interface everywhere.  Making the change
>> will also make it easier to write the hold-out callers to use byte
>> rather than sectors for their iterations; it also makes it easier
>> for a future dirty-bitmap patch to offload scaling over to the
>> internal hbitmap.  Although all callers happen to pass
>> sector-aligned values, make the internal scaling robust to any
>> sub-sector requests.
>>
>> Signed-off-by: Eric Blake 
>> Reviewed-by: John Snow 
> 
> Reviewed-by: Juan Quintela 
> 
> 
>> +
>>  assert(bdrv_dirty_bitmap_enabled(bitmap));
>> -hbitmap_set(bitmap->bitmap, cur_sector, nr_sectors);
>> +hbitmap_set(bitmap->bitmap, offset >> BDRV_SECTOR_BITS,
>> +end_sector - (offset >> BDRV_SECTOR_BITS));
> 
> It is just me, or we use:
> 
> bytes = sectors * BDRV_SECTOR_SIZE
> or
> bytes = sectors << BDRV_SECTOR_BITS

BDRV_SECTOR_SIZE is ULL, while BDRV_SECTOR_BITS is not. Multiplying by
SIZE guarantees a 64-bit answer, but shifting by bits will give only a
32-bit answer if the left hand side of << is not already 64 bits (I've
had bugs in earlier conversion patches where I used << but should have
used *).  So for scaling up, my recent round of patches have been
favoring * (ideally, since BDRV_SECTOR_SIZE is a power-of-2 constant,
the compiler optimizes it into a shift anyways instead of wasting time
on a multiply).

For scaling down, '/ SIZE' and '>> BITS' are equivalent, but I prefer
the >> form.

> 
> and the same from bytes to sectors (no, this patch is consistent,
> but just looking at the file )

The real end-goal is to update the file to track the entire process with
bytes everywhere (and skip the intermediate representation in sectors),
which will reduce the number of scaling operations needed in the first
place.  migration/block.c isn't quite there yet, but we'll get there.

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PULL 03/22] xen-backend: Remove FIXME comment about user_creatable flag

[Eduardo Habkost]

xen-backend can be plugged/unplugged dynamically when using the
Xen accelerator, so keep the user_creatable flag on the device
class and remove the FIXME comment.

Cc: Juergen Gross ,
Cc: Peter Maydell ,
Cc: Thomas Huth 
Cc: sstabell...@kernel.org
Cc: Markus Armbruster ,
Cc: Marcel Apfelbaum ,
Cc: Laszlo Ersek 
Acked-by: Juergen Gross 
Acked-by: Marcel Apfelbaum 
Signed-off-by: Eduardo Habkost 
Message-Id: <20170503203604.31462-4-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 hw/xen/xen_backend.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 2df102a716..8cc0e1e1e5 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -619,10 +619,7 @@ static void xendev_class_init(ObjectClass *klass, void 
*data)
 
 dc->props = xendev_properties;
 set_bit(DEVICE_CATEGORY_MISC, dc->categories);
-/*
- * FIXME: Set only because we are not sure yet if this device
- * will be outside the q35 sysbus whitelist.
- */
+/* xen-backend devices can be plugged/unplugged dynamically */
 dc->user_creatable = true;
 }
 
-- 
2.11.0.259.g40922b1

[Qemu-devel] [PULL 12/22] isabus-bridge: Remove user_creatable flag

[Eduardo Habkost]

isabus-bridge needs to be created by isa_bus_new(), and won't
work with -device, as it won't create the TYPE_ISA_BUS bus
itself. Remove the user_creatable flag from the device class.

Cc: Marcel Apfelbaum 
Cc: "Michael S. Tsirkin" 
Acked-by: Marcel Apfelbaum 
Signed-off-by: Eduardo Habkost 
Message-Id: <20170503203604.31462-13-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 hw/isa/isa-bus.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/hw/isa/isa-bus.c b/hw/isa/isa-bus.c
index ad4ac3b4f6..348e0eab9d 100644
--- a/hw/isa/isa-bus.c
+++ b/hw/isa/isa-bus.c
@@ -221,11 +221,6 @@ static void isabus_bridge_class_init(ObjectClass *klass, 
void *data)
 
 set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
 dc->fw_name = "isa";
-/*
- * FIXME: Set only because we are not sure yet if this device
- * will be outside the q35 sysbus whitelist.
- */
-dc->user_creatable = true;
 }
 
 static const TypeInfo isabus_bridge_info = {
-- 
2.11.0.259.g40922b1

[Qemu-devel] [PULL 04/22] iommu: Remove FIXME comment about user_creatable=true

[Eduardo Habkost]

amd-iommu and intel-iommu are really meant to be used with
-device, so they need user_creatable=true. Remove the FIXME
comment.

Cc: Marcel Apfelbaum 
Cc: "Michael S. Tsirkin" 
Reviewed-by: Marcel Apfelbaum 
Acked-by: Marcel Apfelbaum 
Signed-off-by: Eduardo Habkost 
Message-Id: <20170503203604.31462-5-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 hw/i386/amd_iommu.c   | 5 +
 hw/i386/intel_iommu.c | 5 +
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 7b92c8c15a..efcc93cbfd 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -1186,10 +1186,7 @@ static void amdvi_class_init(ObjectClass *klass, void* 
data)
 dc->vmsd = &vmstate_amdvi;
 dc->hotpluggable = false;
 dc_class->realize = amdvi_realize;
-/*
- * FIXME: Set only because we are not sure yet if this device
- * will be outside the q35 sysbus whitelist.
- */
+/* Supported by the pc-q35-* machine types */
 dc->user_creatable = true;
 }
 
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 54187a04a4..327a46cd19 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -3009,10 +3009,7 @@ static void vtd_class_init(ObjectClass *klass, void 
*data)
 dc->hotpluggable = false;
 x86_class->realize = vtd_realize;
 x86_class->int_remap = vtd_int_remap;
-/*
- * FIXME: Set only because we are not sure yet if this device
- * will be outside the q35 sysbus whitelist.
- */
+/* Supported by the pc-q35-* machine types */
 dc->user_creatable = true;
 }
 
-- 
2.11.0.259.g40922b1

[Qemu-devel] [PULL 19/22] virtio-mmio: Remove user_creatable flag

[Eduardo Habkost]

virtio-mmio needs to be wired and mapped by other device or board
code, and won't work with -device. Remove the user_creatable flag
from the device class.

Cc: Laszlo Ersek 
Cc: Marcel Apfelbaum 
Cc: Peter Maydell 
Cc: Shannon Zhao 
Cc: "Michael S. Tsirkin" 
Reviewed-by: Laszlo Ersek 
Acked-by: Marcel Apfelbaum 
Signed-off-by: Eduardo Habkost 
Message-Id: <20170503203604.31462-20-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 hw/virtio/virtio-mmio.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/hw/virtio/virtio-mmio.c b/hw/virtio/virtio-mmio.c
index 6491a771ff..5807aa87fe 100644
--- a/hw/virtio/virtio-mmio.c
+++ b/hw/virtio/virtio-mmio.c
@@ -450,11 +450,6 @@ static void virtio_mmio_class_init(ObjectClass *klass, 
void *data)
 dc->reset = virtio_mmio_reset;
 set_bit(DEVICE_CATEGORY_MISC, dc->categories);
 dc->props = virtio_mmio_properties;
-/*
- * FIXME: Set only because we are not sure yet if this device
- * will be outside the q35 sysbus whitelist.
- */
-dc->user_creatable = true;
 }
 
 static const TypeInfo virtio_mmio_info = {
-- 
2.11.0.259.g40922b1