Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Neo Jia]

On Tue, Aug 16, 2016 at 04:52:30AM +, Tian, Kevin wrote:
> > From: Neo Jia [mailto:c...@nvidia.com]
> > Sent: Tuesday, August 16, 2016 12:17 PM
> > 
> > On Tue, Aug 16, 2016 at 03:50:44AM +, Tian, Kevin wrote:
> > > > From: Neo Jia [mailto:c...@nvidia.com]
> > > > Sent: Tuesday, August 16, 2016 11:46 AM
> > > >
> > > > On Tue, Aug 16, 2016 at 12:30:25AM +, Tian, Kevin wrote:
> > > > > > From: Neo Jia [mailto:c...@nvidia.com]
> > > > > > Sent: Tuesday, August 16, 2016 3:59 AM
> > > >
> > > > > > > >
> > > > > > > > For NVIDIA vGPU solution we need to know all devices assigned 
> > > > > > > > to a VM in
> > > > > > > > one shot to commit resources of all vGPUs assigned to a VM 
> > > > > > > > along with
> > > > > > > > some common resources.
> > > > > > >
> > > > > > > Kirti, can you elaborate the background about above one-shot 
> > > > > > > commit
> > > > > > > requirement? It's hard to understand such a requirement.
> > > > > > >
> > > > > > > As I relied in another mail, I really hope start/stop become a 
> > > > > > > per-mdev
> > > > > > > attribute instead of global one, e.g.:
> > > > > > >
> > > > > > > echo "0/1" >
> > /sys/class/mdev/12345678-1234-1234-1234-123456789abc/start
> > > > > > >
> > > > > > > In many scenario the user space client may only want to talk to 
> > > > > > > mdev
> > > > > > > instance directly, w/o need to contact its parent device. Still 
> > > > > > > take
> > > > > > > live migration for example, I don't think Qemu wants to know 
> > > > > > > parent
> > > > > > > device of assigned mdev instances.
> > > > > >
> > > > > > Hi Kevin,
> > > > > >
> > > > > > Having a global /sys/class/mdev/mdev_start doesn't require anybody 
> > > > > > to know
> > > > > > parent device. you can just do
> > > > > >
> > > > > > echo "mdev_UUID" > /sys/class/mdev/mdev_start
> > > > > >
> > > > > > or
> > > > > >
> > > > > > echo "mdev_UUID" > /sys/class/mdev/mdev_stop
> > > > > >
> > > > > > without knowing the parent device.
> > > > > >
> > > > >
> > > > > You can look at some existing sysfs example, e.g.:
> > > > >
> > > > > echo "0/1" > /sys/bus/cpu/devices/cpu1/online
> > > > >
> > > > > You may also argue why not using a global style:
> > > > >
> > > > > echo "cpu1" > /sys/bus/cpu/devices/cpu_online
> > > > > echo "cpu1" > /sys/bus/cpu/devices/cpu_offline
> > > > >
> > > > > There are many similar examples...
> > > >
> > > > Hi Kevin,
> > > >
> > > > My response above is to your question about using the global sysfs 
> > > > entry as you
> > > > don't want to have the global path because
> > > >
> > > > "I don't think Qemu wants to know parent device of assigned mdev 
> > > > instances.".
> > > >
> > > > So I just want to confirm with you that (in case you miss):
> > > >
> > > > /sys/class/mdev/mdev_start | mdev_stop
> > > >
> > > > doesn't require the knowledge of parent device.
> > > >
> > >
> > > Qemu is just one example, where your explanation of parent device
> > > makes sense but still it's not good for Qemu to populate /sys/class/mdev
> > > directly. Qemu is passed with the actual sysfs path of assigned mdev
> > > instance, so any mdev attributes touched by Qemu should be put under
> > > that node (e.g. start/stop for live migration usage as I explained 
> > > earlier).
> > 
> > Exactly, qemu is passed with the actual sysfs path.
> > 
> > So, QEMU doesn't touch the file /sys/class/mdev/mdev_start | mdev_stop at 
> > all.
> > 
> > QEMU will take the sysfs path as input:
> > 
> >  -device
> > vfio-pci,sysfsdev=/sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0,i
> > d=vgpu0
> 
> no need of passing "id=vgpu0" here. If necessary you can put id as an 
> attribute 
> under sysfs mdev node:
> 
> /sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0/id

I think we have moved away from the device index based on Alex's comment, so the
device path will be:

 /sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818

> 
> > 
> > As you are saying in live migration, QEMU needs to access "start" and 
> > "stop".  Could you
> > please share more details, such as how QEMU access the "start" and "stop" 
> > sysfs,
> > when and what triggers that?
> > 
> 
> A conceptual flow as below:
> 
> 1. Quiescent mdev activity on the parent device (e.g. stop scheduling, wait 
> for
> in-flight DMA completed, etc.)
> 
> echo "0" > /sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0/start
> 
> 2. Save mdev state:
> 
> cat /sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0/state > xxx
> 
> 3. xxx will be part of the final VM image and copied to a new machine
> 
> 4. Allocate/prepare mdev on the new machine for this VM
> 
> 5. Restore mdev state:
> 
> cat xxx > /sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0/state
> (might be a different path name)
> 
> 6. start mdev on the new parent device:
> 
> echo "1" > /sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0/start

Thanks for the sequence, so based on above live migration, the access 

Re: [Qemu-devel] [PATCH 3/3] ppc/pnv: add a PowerNVCPUCore object

[Benjamin Herrenschmidt]

On Tue, 2016-08-16 at 12:39 +1000, David Gibson wrote:
> On Fri, Aug 05, 2016 at 11:15:37AM +0200, Cédric Le Goater wrote:
> > 
> > This is largy inspired by sPAPRCPUCore with some simplification, no
> > hotplug for instance. But the differences are small and the objects
> > could possibly be merged.
> > 
> > A set of PowerNVCPUCore objects is added to the PnvChip and the device
> > tree is populated looping on these cores. Core ids in the device tree
> > are still a little fuzy. To be checked.

What about P9 where cores are in pairs to form EX and in pairs of EX
(ie, quads) to form EPs ?

> > So, it's not immediately obvious to me if you want an actual core
> object.  You could potentially create the actual vcpu objects directly
> from the chip object.  That assumes that any hotplug will only be at
> chip granularity, not core granularity, but I'm guessing that's the
> case anyway.

Well we want to add some of the core XSCOMs so it makes sense to have
a core object that is a XSCOM device

> > That said, if having the intermediate core object is helpful, you're
> certainly free to have it.
> 
> > 
> > > > Signed-off-by: Cédric Le Goater 
> > ---
> >  hw/ppc/Makefile.objs  |   2 +-
> >  hw/ppc/pnv.c  | 160 ++-
> >  hw/ppc/pnv_core.c | 171 
> > ++
> >  include/hw/ppc/pnv.h  |   7 ++
> >  include/hw/ppc/pnv_core.h |  47 +
> >  5 files changed, 383 insertions(+), 4 deletions(-)
> >  create mode 100644 hw/ppc/pnv_core.c
> >  create mode 100644 include/hw/ppc/pnv_core.h
> > 
> > diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> > index 8105db7d5600..f8c7d1db9ade 100644
> > --- a/hw/ppc/Makefile.objs
> > +++ b/hw/ppc/Makefile.objs
> > @@ -6,7 +6,7 @@ obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o 
> > spapr_rtas.o
> >  obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o spapr_rng.o
> >  obj-$(CONFIG_PSERIES) += spapr_cpu_core.o
> >  # IBM PowerNV
> > -obj-$(CONFIG_POWERNV) += pnv.o
> > +obj-$(CONFIG_POWERNV) += pnv.o pnv_core.o
> >  ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
> >  obj-y += spapr_pci_vfio.o
> >  endif
> > diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> > index a680780e9dea..1219493c7218 100644
> > --- a/hw/ppc/pnv.c
> > +++ b/hw/ppc/pnv.c
> > @@ -35,6 +35,7 @@
> >  #include "hw/ppc/fdt.h"
> >  #include "hw/ppc/ppc.h"
> >  #include "hw/ppc/pnv.h"
> > +#include "hw/ppc/pnv_core.h"
> >  #include "hw/loader.h"
> >  #include "exec/address-spaces.h"
> >  #include "qemu/cutils.h"
> > @@ -112,6 +113,114 @@ static int powernv_populate_memory(void *fdt)
> >  return 0;
> >  }
> >  
> > +static void powernv_create_core_node(void *fdt, CPUState *cs, uint32_t 
> > chip_id)
> > +{
> > +PowerPCCPU *cpu = POWERPC_CPU(cs);
> > +int smt_threads = ppc_get_compat_smt_threads(cpu);
> > +CPUPPCState *env = >env;
> > +DeviceClass *dc = DEVICE_GET_CLASS(cs);
> > +PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cs);
> > +uint32_t servers_prop[smt_threads];
> > +uint32_t gservers_prop[smt_threads * 2];
> > +int i, index = ppc_get_vcpu_dt_id(cpu);
> > +uint32_t segs[] = {cpu_to_be32(28), cpu_to_be32(40),
> > +   0x, 0x};
> > +uint32_t tbfreq = PNV_TIMEBASE_FREQ;
> > +uint32_t cpufreq = 10;
> > +uint32_t page_sizes_prop[64];
> > +size_t page_sizes_prop_size;
> > +char *nodename;
> > +
> > +nodename = g_strdup_printf("%s@%x", dc->fw_name, index);
> > +
> > +_FDT((fdt_begin_node(fdt, nodename)));
> > +
> > +g_free(nodename);
> > +
> > +_FDT((fdt_property_cell(fdt, "reg", index)));
> > +_FDT((fdt_property_string(fdt, "device_type", "cpu")));
> 
> The handling of dt_id is going to collide with cleanups I want to do
> in this area (for spapr and the ppc cpu core).  Not sure there's a lot
> you can do to avoid that at this stage.
> 
> > 
> > +_FDT((fdt_property_cell(fdt, "cpu-version", env->spr[SPR_PVR])));
> > +_FDT((fdt_property_cell(fdt, "d-cache-block-size",
> > +env->dcache_line_size)));
> > +_FDT((fdt_property_cell(fdt, "d-cache-line-size",
> > +env->dcache_line_size)));
> > +_FDT((fdt_property_cell(fdt, "i-cache-block-size",
> > +env->icache_line_size)));
> > +_FDT((fdt_property_cell(fdt, "i-cache-line-size",
> > +env->icache_line_size)));
> > +
> > +if (pcc->l1_dcache_size) {
> > +_FDT((fdt_property_cell(fdt, "d-cache-size", 
> > pcc->l1_dcache_size)));
> > +} else {
> > +error_report("Warning: Unknown L1 dcache size for cpu");
> > +}
> > +if (pcc->l1_icache_size) {
> > +_FDT((fdt_property_cell(fdt, "i-cache-size", 
> > pcc->l1_icache_size)));
> > +} else {
> > +error_report("Warning: Unknown L1 icache size for cpu");
> > +}
> > +
> > +

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Tian, Kevin]

> From: Neo Jia [mailto:c...@nvidia.com]
> Sent: Tuesday, August 16, 2016 12:17 PM
> 
> On Tue, Aug 16, 2016 at 03:50:44AM +, Tian, Kevin wrote:
> > > From: Neo Jia [mailto:c...@nvidia.com]
> > > Sent: Tuesday, August 16, 2016 11:46 AM
> > >
> > > On Tue, Aug 16, 2016 at 12:30:25AM +, Tian, Kevin wrote:
> > > > > From: Neo Jia [mailto:c...@nvidia.com]
> > > > > Sent: Tuesday, August 16, 2016 3:59 AM
> > >
> > > > > > >
> > > > > > > For NVIDIA vGPU solution we need to know all devices assigned to 
> > > > > > > a VM in
> > > > > > > one shot to commit resources of all vGPUs assigned to a VM along 
> > > > > > > with
> > > > > > > some common resources.
> > > > > >
> > > > > > Kirti, can you elaborate the background about above one-shot commit
> > > > > > requirement? It's hard to understand such a requirement.
> > > > > >
> > > > > > As I relied in another mail, I really hope start/stop become a 
> > > > > > per-mdev
> > > > > > attribute instead of global one, e.g.:
> > > > > >
> > > > > > echo "0/1" >
> /sys/class/mdev/12345678-1234-1234-1234-123456789abc/start
> > > > > >
> > > > > > In many scenario the user space client may only want to talk to mdev
> > > > > > instance directly, w/o need to contact its parent device. Still take
> > > > > > live migration for example, I don't think Qemu wants to know parent
> > > > > > device of assigned mdev instances.
> > > > >
> > > > > Hi Kevin,
> > > > >
> > > > > Having a global /sys/class/mdev/mdev_start doesn't require anybody to 
> > > > > know
> > > > > parent device. you can just do
> > > > >
> > > > > echo "mdev_UUID" > /sys/class/mdev/mdev_start
> > > > >
> > > > > or
> > > > >
> > > > > echo "mdev_UUID" > /sys/class/mdev/mdev_stop
> > > > >
> > > > > without knowing the parent device.
> > > > >
> > > >
> > > > You can look at some existing sysfs example, e.g.:
> > > >
> > > > echo "0/1" > /sys/bus/cpu/devices/cpu1/online
> > > >
> > > > You may also argue why not using a global style:
> > > >
> > > > echo "cpu1" > /sys/bus/cpu/devices/cpu_online
> > > > echo "cpu1" > /sys/bus/cpu/devices/cpu_offline
> > > >
> > > > There are many similar examples...
> > >
> > > Hi Kevin,
> > >
> > > My response above is to your question about using the global sysfs entry 
> > > as you
> > > don't want to have the global path because
> > >
> > > "I don't think Qemu wants to know parent device of assigned mdev 
> > > instances.".
> > >
> > > So I just want to confirm with you that (in case you miss):
> > >
> > > /sys/class/mdev/mdev_start | mdev_stop
> > >
> > > doesn't require the knowledge of parent device.
> > >
> >
> > Qemu is just one example, where your explanation of parent device
> > makes sense but still it's not good for Qemu to populate /sys/class/mdev
> > directly. Qemu is passed with the actual sysfs path of assigned mdev
> > instance, so any mdev attributes touched by Qemu should be put under
> > that node (e.g. start/stop for live migration usage as I explained earlier).
> 
> Exactly, qemu is passed with the actual sysfs path.
> 
> So, QEMU doesn't touch the file /sys/class/mdev/mdev_start | mdev_stop at all.
> 
> QEMU will take the sysfs path as input:
> 
>  -device
> vfio-pci,sysfsdev=/sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0,i
> d=vgpu0

no need of passing "id=vgpu0" here. If necessary you can put id as an attribute 
under sysfs mdev node:

/sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0/id

> 
> As you are saying in live migration, QEMU needs to access "start" and "stop". 
>  Could you
> please share more details, such as how QEMU access the "start" and "stop" 
> sysfs,
> when and what triggers that?
> 

A conceptual flow as below:

1. Quiescent mdev activity on the parent device (e.g. stop scheduling, wait for
in-flight DMA completed, etc.)

echo "0" > /sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0/start

2. Save mdev state:

cat /sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0/state > xxx

3. xxx will be part of the final VM image and copied to a new machine

4. Allocate/prepare mdev on the new machine for this VM

5. Restore mdev state:

cat xxx > /sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0/state
(might be a different path name)

6. start mdev on the new parent device:

echo "1" > /sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0/start

Thanks
Kevin

Re: [Qemu-devel] [PATCH v3 1/5] target-ppc: add vector insert instructions

[David Gibson]

On Thu, Aug 11, 2016 at 01:06:44PM +0530, Rajalakshmi Srinivasaraghavan wrote:
> The following vector insert instructions are added from ISA 3.0.
> 
> vinsertb - Vector Insert Byte
> vinserth - Vector Insert Halfword
> vinsertw - Vector Insert Word
> vinsertd - Vector Insert Doubleword
> 
> Signed-off-by: Rajalakshmi Srinivasaraghavan 
> ---
>  target-ppc/helper.h |4 
>  target-ppc/int_helper.c |   27 +++
>  target-ppc/translate.c  |2 ++
>  target-ppc/translate/vmx-impl.c |   32 
>  target-ppc/translate/vmx-ops.c  |   18 +-
>  5 files changed, 78 insertions(+), 5 deletions(-)
> 
> diff --git a/target-ppc/helper.h b/target-ppc/helper.h
> index 93ac9e1..0923779 100644
> --- a/target-ppc/helper.h
> +++ b/target-ppc/helper.h
> @@ -250,6 +250,10 @@ DEF_HELPER_2(vspltisw, void, avr, i32)
>  DEF_HELPER_3(vspltb, void, avr, avr, i32)
>  DEF_HELPER_3(vsplth, void, avr, avr, i32)
>  DEF_HELPER_3(vspltw, void, avr, avr, i32)
> +DEF_HELPER_3(vinsertb, void, avr, avr, i32)
> +DEF_HELPER_3(vinserth, void, avr, avr, i32)
> +DEF_HELPER_3(vinsertw, void, avr, avr, i32)
> +DEF_HELPER_3(vinsertd, void, avr, avr, i32)
>  DEF_HELPER_2(vupkhpx, void, avr, avr)
>  DEF_HELPER_2(vupklpx, void, avr, avr)
>  DEF_HELPER_2(vupkhsb, void, avr, avr)
> diff --git a/target-ppc/int_helper.c b/target-ppc/int_helper.c
> index 552b2e0..3f8e439 100644
> --- a/target-ppc/int_helper.c
> +++ b/target-ppc/int_helper.c
> @@ -1792,6 +1792,33 @@ VSPLT(w, u32)
>  #undef VSPLT
>  #undef SPLAT_ELEMENT
>  #undef _SPLAT_MASKED
> +#if defined(HOST_WORDS_BIGENDIAN)
> +#define VINSERT(suffix, element, index) \
> +void helper_vinsert##suffix(ppc_avr_t *r, ppc_avr_t *b, uint32_t splat) \
> +{   \
> +ppc_avr_t result;   \
> +result = *r;\
> +memcpy([splat], >element[index],   \
> +   sizeof(result.element[0]));  \
> +*r = result;\

Using a temporary for the result means two extra full vector copies,
which seems unfortunate.  Couldn't you just use memmove() instead of
memcpy() to handle the overlapping cases?

> +}
> +#else
> +#define VINSERT(suffix, element, index) \
> +void helper_vinsert##suffix(ppc_avr_t *r, ppc_avr_t *b, uint32_t splat) \
> +{   \
> +ppc_avr_t result;   \
> +result = *r;\
> +uint32_t s = (ARRAY_SIZE(r->element) - index) - 1;  \

The logic with index seems a bit convoluted.  AFAICT the index is
always the least significant element of the most-significant half of
the vector b.  So for BE [8] should always be right and for
LE [8 - sizeof(r->element)].

> +uint32_t d = (16 - splat) - sizeof(r->element[0]);  \
> +memcpy([d], >element[s], sizeof(result.element[0]));   \
> +*r = result;\
> +}
> +#endif
> +VINSERT(b, u8, 7)
> +VINSERT(h, u16, 3)
> +VINSERT(w, u32, 1)
> +VINSERT(d, u64, 0)
> +#undef VINSERT
>  
>  #define VSPLTI(suffix, element, splat_type) \
>  void helper_vspltis##suffix(ppc_avr_t *r, uint32_t splat)   \
> diff --git a/target-ppc/translate.c b/target-ppc/translate.c
> index fc3d371..dbe952e 100644
> --- a/target-ppc/translate.c
> +++ b/target-ppc/translate.c
> @@ -498,6 +498,8 @@ EXTRACT_HELPER(UIMM, 0, 16);
>  EXTRACT_HELPER(SIMM5, 16, 5);
>  /* 5 bits signed immediate value */
>  EXTRACT_HELPER(UIMM5, 16, 5);
> +/* 4 bits unsigned immediate value */
> +EXTRACT_HELPER(UIMM4, 16, 4);
>  /* Bit count */
>  EXTRACT_HELPER(NB, 11, 5);
>  /* Shift count */
> diff --git a/target-ppc/translate/vmx-impl.c b/target-ppc/translate/vmx-impl.c
> index ac78caf..f6a97ac 100644
> --- a/target-ppc/translate/vmx-impl.c
> +++ b/target-ppc/translate/vmx-impl.c
> @@ -623,13 +623,45 @@ static void glue(gen_, name)(DisasContext *ctx) 
> \
>  tcg_temp_free_ptr(rd);  \
>  }
>  
> +#define GEN_VXFORM_UIMM_SPLAT(name, opc2, opc3, splat_max)  \
> +static void glue(gen_, name)(DisasContext *ctx) \
> +{   \
> +TCGv_ptr rb, rd;\
> +uint8_t uimm = UIMM4(ctx->opcode);  \
> +TCGv_i32 t0 = tcg_temp_new_i32(); 

Re: [Qemu-devel] [PATCH v3 3/5] target-ppc: add vector count trailing zeros instructions

[David Gibson]

On Thu, Aug 11, 2016 at 01:06:46PM +0530, Rajalakshmi Srinivasaraghavan wrote:
> The following vector count trailing zeros instructions are
> added from ISA 3.0.
> 
> vctzb - Vector Count Trailing Zeros Byte
> vctzh - Vector Count Trailing Zeros Halfword
> vctzw - Vector Count Trailing Zeros Word
> vctzd - Vector Count Trailing Zeros Doubleword
> 
> Signed-off-by: Rajalakshmi Srinivasaraghavan 

Reviewed-by: David Gibson 

However, it needs a rebase.

> ---
>  target-ppc/helper.h |4 
>  target-ppc/int_helper.c |   15 +++
>  target-ppc/translate/vmx-impl.c |   19 +++
>  target-ppc/translate/vmx-ops.c  |8 
>  4 files changed, 46 insertions(+), 0 deletions(-)
> 
> diff --git a/target-ppc/helper.h b/target-ppc/helper.h
> index 59e7b88..6e6e7b3 100644
> --- a/target-ppc/helper.h
> +++ b/target-ppc/helper.h
> @@ -327,6 +327,10 @@ DEF_HELPER_2(vclzb, void, avr, avr)
>  DEF_HELPER_2(vclzh, void, avr, avr)
>  DEF_HELPER_2(vclzw, void, avr, avr)
>  DEF_HELPER_2(vclzd, void, avr, avr)
> +DEF_HELPER_2(vctzb, void, avr, avr)
> +DEF_HELPER_2(vctzh, void, avr, avr)
> +DEF_HELPER_2(vctzw, void, avr, avr)
> +DEF_HELPER_2(vctzd, void, avr, avr)
>  DEF_HELPER_2(vpopcntb, void, avr, avr)
>  DEF_HELPER_2(vpopcnth, void, avr, avr)
>  DEF_HELPER_2(vpopcntw, void, avr, avr)
> diff --git a/target-ppc/int_helper.c b/target-ppc/int_helper.c
> index a917bd5..162f1e9 100644
> --- a/target-ppc/int_helper.c
> +++ b/target-ppc/int_helper.c
> @@ -2091,6 +2091,21 @@ VGENERIC_DO(clzd, u64)
>  #undef clzw
>  #undef clzd
>  
> +#define ctzb(v) ((v) ? ctz32(v) : 8)
> +#define ctzh(v) ((v) ? ctz32(v) : 16)
> +#define ctzw(v) ctz32((v))
> +#define ctzd(v) ctz64((v))
> +
> +VGENERIC_DO(ctzb, u8)
> +VGENERIC_DO(ctzh, u16)
> +VGENERIC_DO(ctzw, u32)
> +VGENERIC_DO(ctzd, u64)
> +
> +#undef ctzb
> +#undef ctzh
> +#undef ctzw
> +#undef ctzd
> +
>  #define popcntb(v) ctpop8(v)
>  #define popcnth(v) ctpop16(v)
>  #define popcntw(v) ctpop32(v)
> diff --git a/target-ppc/translate/vmx-impl.c b/target-ppc/translate/vmx-impl.c
> index 766a645..ebf123f 100644
> --- a/target-ppc/translate/vmx-impl.c
> +++ b/target-ppc/translate/vmx-impl.c
> @@ -553,6 +553,21 @@ static void glue(gen_, name)(DisasContext *ctx)  
>\
>  tcg_temp_free_ptr(rd);  \
>  }
>  
> +#define GEN_VXFORM_NOA_2(name, opc2, opc3, opc4)\
> +static void glue(gen_, name)(DisasContext *ctx) \
> +{   \
> +TCGv_ptr rb, rd;\
> +if (unlikely(!ctx->altivec_enabled)) {  \
> +gen_exception(ctx, POWERPC_EXCP_VPU);   \
> +return; \
> +}   \
> +rb = gen_avr_ptr(rB(ctx->opcode));  \
> +rd = gen_avr_ptr(rD(ctx->opcode));  \
> +gen_helper_##name(rd, rb);  \
> +tcg_temp_free_ptr(rb);  \
> +tcg_temp_free_ptr(rd);  \
> +}
> +
>  GEN_VXFORM_NOA(vupkhsb, 7, 8);
>  GEN_VXFORM_NOA(vupkhsh, 7, 9);
>  GEN_VXFORM_NOA(vupkhsw, 7, 25);
> @@ -745,6 +760,10 @@ GEN_VXFORM_NOA(vclzb, 1, 28)
>  GEN_VXFORM_NOA(vclzh, 1, 29)
>  GEN_VXFORM_NOA(vclzw, 1, 30)
>  GEN_VXFORM_NOA(vclzd, 1, 31)
> +GEN_VXFORM_NOA_2(vctzb, 1, 24, 28)
> +GEN_VXFORM_NOA_2(vctzh, 1, 24, 29)
> +GEN_VXFORM_NOA_2(vctzw, 1, 24, 30)
> +GEN_VXFORM_NOA_2(vctzd, 1, 24, 31)
>  GEN_VXFORM_NOA(vpopcntb, 1, 28)
>  GEN_VXFORM_NOA(vpopcnth, 1, 29)
>  GEN_VXFORM_NOA(vpopcntw, 1, 30)
> diff --git a/target-ppc/translate/vmx-ops.c b/target-ppc/translate/vmx-ops.c
> index aafe70b..5b2826e 100644
> --- a/target-ppc/translate/vmx-ops.c
> +++ b/target-ppc/translate/vmx-ops.c
> @@ -44,6 +44,10 @@ GEN_HANDLER_E(name, 0x04, opc2, opc3, 0x, 
> PPC_NONE, PPC2_ISA300)
>  #define GEN_VXFORM_300_EXT(name, opc2, opc3, inval) \
>  GEN_HANDLER_E(name, 0x04, opc2, opc3, inval, PPC_NONE, PPC2_ISA300)
>  
> +#define GEN_VXFORM_300_EO(name, opc2, opc3, opc4) \
> +GEN_HANDLER_E_2(name, 0x04, opc2, opc3, opc4, 0x, PPC_NONE, \
> +   PPC2_ISA300)
> +
>  #define GEN_VXFORM_DUAL(name0, name1, opc2, opc3, type0, type1) \
>  GEN_HANDLER_E(name0##_##name1, 0x4, opc2, opc3, 0x, type0, type1)
>  
> @@ -211,6 +215,10 @@ GEN_VXFORM_DUAL_INV(vspltish, vinserth, 6, 13, 
> 0x, 0x10,
>  GEN_VXFORM_DUAL_INV(vspltisw, vinsertw, 6, 14, 0x, 0x10,
> 

Re: [Qemu-devel] [PATCH v3 2/5] target-ppc: add vector extract instructions

[David Gibson]

On Thu, Aug 11, 2016 at 01:06:45PM +0530, Rajalakshmi Srinivasaraghavan wrote:
> The following vector extract instructions are added from ISA 3.0.
> 
> vextractub - Vector Extract Unsigned Byte
> vextractuh - Vector Extract Unsigned Halfword
> vextractuw - Vector Extract Unsigned Word
> vextractd - Vector Extract Unsigned Doubleword
> 
> Signed-off-by: Rajalakshmi Srinivasaraghavan 
> ---
>  target-ppc/helper.h |4 
>  target-ppc/int_helper.c |   26 ++
>  target-ppc/translate/vmx-impl.c |   10 ++
>  target-ppc/translate/vmx-ops.c  |   10 +++---
>  4 files changed, 47 insertions(+), 3 deletions(-)
> 
> diff --git a/target-ppc/helper.h b/target-ppc/helper.h
> index 0923779..59e7b88 100644
> --- a/target-ppc/helper.h
> +++ b/target-ppc/helper.h
> @@ -250,6 +250,10 @@ DEF_HELPER_2(vspltisw, void, avr, i32)
>  DEF_HELPER_3(vspltb, void, avr, avr, i32)
>  DEF_HELPER_3(vsplth, void, avr, avr, i32)
>  DEF_HELPER_3(vspltw, void, avr, avr, i32)
> +DEF_HELPER_3(vextractub, void, avr, avr, i32)
> +DEF_HELPER_3(vextractuh, void, avr, avr, i32)
> +DEF_HELPER_3(vextractuw, void, avr, avr, i32)
> +DEF_HELPER_3(vextractd, void, avr, avr, i32)
>  DEF_HELPER_3(vinsertb, void, avr, avr, i32)
>  DEF_HELPER_3(vinserth, void, avr, avr, i32)
>  DEF_HELPER_3(vinsertw, void, avr, avr, i32)
> diff --git a/target-ppc/int_helper.c b/target-ppc/int_helper.c
> index 3f8e439..a917bd5 100644
> --- a/target-ppc/int_helper.c
> +++ b/target-ppc/int_helper.c
> @@ -1819,6 +1819,32 @@ VINSERT(h, u16, 3)
>  VINSERT(w, u32, 1)
>  VINSERT(d, u64, 0)
>  #undef VINSERT
> +#if defined(HOST_WORDS_BIGENDIAN)
> +#define VEXTRACT(suffix, element, index) 
> \
> +void helper_vextract##suffix(ppc_avr_t *r, ppc_avr_t *b, uint32_t splat) 
> \

splat is not a good parameter name here, since the element is being
extracted, rather than splatted.

> +{
> \
> +uint32_t s = sizeof(r->element[0]) * index;  
> \
> +ppc_avr_t result = { .u64 = { 0, 0 } };  
> \
> +memcpy([index], >u8[splat],
> \
> +   sizeof(result.element[0]));   
> \
> +*r = result; 
> \
> +}
> +#else
> +#define VEXTRACT(suffix, element, index) 
> \
> +void helper_vextract##suffix(ppc_avr_t *r, ppc_avr_t *b, uint32_t splat) 
> \
> +{
> \
> +ppc_avr_t result = { .u64 = { 0, 0 } };  
> \
> +uint32_t s = (16 - splat) - sizeof(r->element[0]);   
> \
> +uint32_t d = (ARRAY_SIZE(r->element) - index) - 1;
> \

Same comments on the index value as for vinsert*.

> +memcpy([d], >u8[s], sizeof(result.element[0]));
> \
> +*r = result; 
> \
> +}
> +#endif
> +VEXTRACT(ub, u8, 7)
> +VEXTRACT(uh, u16, 3)
> +VEXTRACT(uw, u32, 1)
> +VEXTRACT(d, u64, 0)
> +#undef VEXTRACT
>  
>  #define VSPLTI(suffix, element, splat_type) \
>  void helper_vspltis##suffix(ppc_avr_t *r, uint32_t splat)   \
> diff --git a/target-ppc/translate/vmx-impl.c b/target-ppc/translate/vmx-impl.c
> index f6a97ac..766a645 100644
> --- a/target-ppc/translate/vmx-impl.c
> +++ b/target-ppc/translate/vmx-impl.c
> @@ -648,6 +648,10 @@ static void glue(gen_, name)(DisasContext *ctx)  
>\
>  GEN_VXFORM_UIMM(vspltb, 6, 8);
>  GEN_VXFORM_UIMM(vsplth, 6, 9);
>  GEN_VXFORM_UIMM(vspltw, 6, 10);
> +GEN_VXFORM_UIMM_SPLAT(vextractub, 6, 8, 15);
> +GEN_VXFORM_UIMM_SPLAT(vextractuh, 6, 9, 14);
> +GEN_VXFORM_UIMM_SPLAT(vextractuw, 6, 10, 12);
> +GEN_VXFORM_UIMM_SPLAT(vextractd, 6, 11, 8);
>  GEN_VXFORM_UIMM_SPLAT(vinsertb, 6, 12, 15);
>  GEN_VXFORM_UIMM_SPLAT(vinserth, 6, 13, 14);
>  GEN_VXFORM_UIMM_SPLAT(vinsertw, 6, 14, 12);
> @@ -656,6 +660,12 @@ GEN_VXFORM_UIMM_ENV(vcfux, 5, 12);
>  GEN_VXFORM_UIMM_ENV(vcfsx, 5, 13);
>  GEN_VXFORM_UIMM_ENV(vctuxs, 5, 14);
>  GEN_VXFORM_UIMM_ENV(vctsxs, 5, 15);
> +GEN_VXFORM_DUAL(vspltb, PPC_NONE, PPC2_ALTIVEC_207,
> +  vextractub, PPC_NONE, PPC2_ISA300);
> +GEN_VXFORM_DUAL(vsplth, PPC_NONE, PPC2_ALTIVEC_207,
> +  vextractuh, PPC_NONE, PPC2_ISA300);
> +GEN_VXFORM_DUAL(vspltw, PPC_NONE, PPC2_ALTIVEC_207,
> +  vextractuw, PPC_NONE, PPC2_ISA300);
>  GEN_VXFORM_DUAL(vspltisb, PPC_NONE, PPC2_ALTIVEC_207,
>vinsertb, PPC_NONE, PPC2_ISA300);
>  GEN_VXFORM_DUAL(vspltish, PPC_NONE, PPC2_ALTIVEC_207,
> diff --git a/target-ppc/translate/vmx-ops.c b/target-ppc/translate/vmx-ops.c
> index ca69e56..aafe70b 100644
> --- 

Re: [Qemu-devel] [PATCH v3 4/5] target-ppc: add vector bit permute doubleword instruction

[David Gibson]

On Thu, Aug 11, 2016 at 01:06:47PM +0530, Rajalakshmi Srinivasaraghavan wrote:
> Add vbpermd instruction from ISA 3.0.
> 
> Signed-off-by: Rajalakshmi Srinivasaraghavan 
> ---
>  target-ppc/helper.h |1 +
>  target-ppc/int_helper.c |   22 ++
>  target-ppc/translate/vmx-impl.c |1 +
>  target-ppc/translate/vmx-ops.c  |1 +
>  4 files changed, 25 insertions(+), 0 deletions(-)
> 
> diff --git a/target-ppc/helper.h b/target-ppc/helper.h
> index 6e6e7b3..d1d9418 100644
> --- a/target-ppc/helper.h
> +++ b/target-ppc/helper.h
> @@ -335,6 +335,7 @@ DEF_HELPER_2(vpopcntb, void, avr, avr)
>  DEF_HELPER_2(vpopcnth, void, avr, avr)
>  DEF_HELPER_2(vpopcntw, void, avr, avr)
>  DEF_HELPER_2(vpopcntd, void, avr, avr)
> +DEF_HELPER_3(vbpermd, void, avr, avr, avr)
>  DEF_HELPER_3(vbpermq, void, avr, avr, avr)
>  DEF_HELPER_2(vgbbd, void, avr, avr)
>  DEF_HELPER_3(vpmsumb, void, avr, avr, avr)
> diff --git a/target-ppc/int_helper.c b/target-ppc/int_helper.c
> index 162f1e9..6bed3b6 100644
> --- a/target-ppc/int_helper.c
> +++ b/target-ppc/int_helper.c
> @@ -1134,6 +1134,28 @@ void helper_vperm(CPUPPCState *env, ppc_avr_t *r, 
> ppc_avr_t *a, ppc_avr_t *b,
>  #define VBPERMQ_DW(index) (((index) & 0x40) == 0)
>  #endif
>  
> +void helper_vbpermd(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)
> +{
> +int i, j;
> +uint64_t perm = 0;
> +ppc_avr_t result;
> +
> +VECTOR_FOR_INORDER_I(i, u64) {
> +perm = 0;

Since you already have a temporary for the whole result vector, you
shouldn't need a temporary for the individual result dwords.

> +for (j = 0; j < 8; j++) {
> +int index = VBPERMQ_INDEX(b, (i * 8) + j);
> +if (index < 64) {
> +uint64_t mask = (1ull << (63 - (index & 0x3F)));
> +if (a->u64[VBPERMQ_DW(index)] & mask) {
> +perm |= (0x80 >> j);
> +}

It would probably be nice to avoid the conditional branch probably
created by this innermost if, which should be possible given you can
extract the actual value of the bit you're inserting.

> +}
> +}
> +result.u64[i] = perm;
> +}
> +*r = result;
> +}
> +
>  void helper_vbpermq(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)
>  {
>  int i;
> diff --git a/target-ppc/translate/vmx-impl.c b/target-ppc/translate/vmx-impl.c
> index ebf123f..38f8ad7 100644
> --- a/target-ppc/translate/vmx-impl.c
> +++ b/target-ppc/translate/vmx-impl.c
> @@ -776,6 +776,7 @@ GEN_VXFORM_DUAL(vclzw, PPC_NONE, PPC2_ALTIVEC_207, \
>  vpopcntw, PPC_NONE, PPC2_ALTIVEC_207)
>  GEN_VXFORM_DUAL(vclzd, PPC_NONE, PPC2_ALTIVEC_207, \
>  vpopcntd, PPC_NONE, PPC2_ALTIVEC_207)
> +GEN_VXFORM(vbpermd, 6, 23);
>  GEN_VXFORM(vbpermq, 6, 21);
>  GEN_VXFORM_NOA(vgbbd, 6, 20);
>  GEN_VXFORM(vpmsumb, 4, 16)
> diff --git a/target-ppc/translate/vmx-ops.c b/target-ppc/translate/vmx-ops.c
> index 5b2826e..32bd533 100644
> --- a/target-ppc/translate/vmx-ops.c
> +++ b/target-ppc/translate/vmx-ops.c
> @@ -261,6 +261,7 @@ GEN_VXFORM_DUAL(vclzh, vpopcnth, 1, 29, PPC_NONE, 
> PPC2_ALTIVEC_207),
>  GEN_VXFORM_DUAL(vclzw, vpopcntw, 1, 30, PPC_NONE, PPC2_ALTIVEC_207),
>  GEN_VXFORM_DUAL(vclzd, vpopcntd, 1, 31, PPC_NONE, PPC2_ALTIVEC_207),
>  
> +GEN_VXFORM_300(vbpermd, 6, 23),
>  GEN_VXFORM_207(vbpermq, 6, 21),
>  GEN_VXFORM_207(vgbbd, 6, 20),
>  GEN_VXFORM_207(vpmsumb, 4, 16),

-- 
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 5/5] target-ppc: add vector permute right indexed instruction

[David Gibson]

On Thu, Aug 11, 2016 at 01:06:48PM +0530, Rajalakshmi Srinivasaraghavan wrote:
> Add vpermr instruction from ISA 3.0.
> 
> Signed-off-by: Rajalakshmi Srinivasaraghavan 
> ---
>  target-ppc/helper.h |1 +
>  target-ppc/int_helper.c |   23 +++
>  target-ppc/translate/vmx-impl.c |   18 ++
>  target-ppc/translate/vmx-ops.c  |1 +
>  4 files changed, 43 insertions(+), 0 deletions(-)
> 
> diff --git a/target-ppc/helper.h b/target-ppc/helper.h
> index d1d9418..3c476c9 100644
> --- a/target-ppc/helper.h
> +++ b/target-ppc/helper.h
> @@ -270,6 +270,7 @@ DEF_HELPER_5(vmsumubm, void, env, avr, avr, avr, avr)
>  DEF_HELPER_5(vmsummbm, void, env, avr, avr, avr, avr)
>  DEF_HELPER_5(vsel, void, env, avr, avr, avr, avr)
>  DEF_HELPER_5(vperm, void, env, avr, avr, avr, avr)
> +DEF_HELPER_5(vpermr, void, env, avr, avr, avr, avr)
>  DEF_HELPER_4(vpkshss, void, env, avr, avr, avr)
>  DEF_HELPER_4(vpkshus, void, env, avr, avr, avr)
>  DEF_HELPER_4(vpkswss, void, env, avr, avr, avr)
> diff --git a/target-ppc/int_helper.c b/target-ppc/int_helper.c
> index 6bed3b6..a35355f 100644
> --- a/target-ppc/int_helper.c
> +++ b/target-ppc/int_helper.c
> @@ -1126,6 +1126,29 @@ void helper_vperm(CPUPPCState *env, ppc_avr_t *r, 
> ppc_avr_t *a, ppc_avr_t *b,
>  *r = result;
>  }
>  
> +void helper_vpermr(CPUPPCState *env, ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t 
> *b,
> +  ppc_avr_t *c)
> +{
> +ppc_avr_t result;
> +int i;
> +
> +VECTOR_FOR_INORDER_I(i, u8) {
> +int s = c->u8[i] & 0x1f;
> +#if defined(HOST_WORDS_BIGENDIAN)
> +int index = 15 - (s & 0xf);
> +#else
> +int index = s & 0xf;
> +#endif
> +
> +if (s & 0x10) {
> +result.u8[i] = a->u8[index];
> +} else {
> +result.u8[i] = b->u8[index];
> +}
> +}
> +*r = result;
> +}
> +
>  #if defined(HOST_WORDS_BIGENDIAN)
>  #define VBPERMQ_INDEX(avr, i) ((avr)->u8[(i)])
>  #define VBPERMQ_DW(index) (((index) & 0x40) != 0)
> diff --git a/target-ppc/translate/vmx-impl.c b/target-ppc/translate/vmx-impl.c
> index 38f8ad7..feb10de 100644
> --- a/target-ppc/translate/vmx-impl.c
> +++ b/target-ppc/translate/vmx-impl.c
> @@ -750,6 +750,24 @@ static void gen_vmladduhm(DisasContext *ctx)
>  tcg_temp_free_ptr(rd);
>  }
>  
> +static void gen_vpermr(DisasContext *ctx)
> +{
> +TCGv_ptr ra, rb, rc, rd;
> +if (unlikely(!ctx->altivec_enabled)) {
> +gen_exception(ctx, POWERPC_EXCP_VPU);
> +return;
> +}
> +ra = gen_avr_ptr(rA(ctx->opcode));
> +rb = gen_avr_ptr(rB(ctx->opcode));
> +rc = gen_avr_ptr(rC(ctx->opcode));
> +rd = gen_avr_ptr(rD(ctx->opcode));
> +gen_helper_vpermr(cpu_env, rd, ra, rb, rc);
> +tcg_temp_free_ptr(ra);
> +tcg_temp_free_ptr(rb);
> +tcg_temp_free_ptr(rc);
> +tcg_temp_free_ptr(rd);
> +}

Why do you need this gen_vpermr() function while there isn't a
matching gen_vperm()?

> +
>  GEN_VAFORM_PAIRED(vmsumubm, vmsummbm, 18)
>  GEN_VAFORM_PAIRED(vmsumuhm, vmsumuhs, 19)
>  GEN_VAFORM_PAIRED(vmsumshm, vmsumshs, 20)
> diff --git a/target-ppc/translate/vmx-ops.c b/target-ppc/translate/vmx-ops.c
> index 32bd533..ad72db5 100644
> --- a/target-ppc/translate/vmx-ops.c
> +++ b/target-ppc/translate/vmx-ops.c
> @@ -219,6 +219,7 @@ GEN_VXFORM_300_EO(vctzb, 0x01, 0x18, 0x1C),
>  GEN_VXFORM_300_EO(vctzh, 0x01, 0x18, 0x1D),
>  GEN_VXFORM_300_EO(vctzw, 0x01, 0x18, 0x1E),
>  GEN_VXFORM_300_EO(vctzd, 0x01, 0x18, 0x1F),
> +GEN_VXFORM_300(vpermr, 0x1D, 0xFF),
>  
>  #define GEN_VXFORM_NOA(name, opc2, opc3)\
>  GEN_HANDLER(name, 0x04, opc2, opc3, 0x001f, PPC_ALTIVEC)

-- 
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

[Qemu-devel] Virtio interaction with the physical device

[Gadre Nayan]

Hi,

I was trying to understand the flow of packets from the Guest OS to my
NIC card, while using the Virtio paravirtualized drivers. (Qemu is not
emulating the NIC)

THis is as far as I have understood:
{
THe guest OS starts with a virtio nic:
-net nic,model=virtio -net user -redir tcp:::22

A socket application sends data on an interface (which would have been
created by this nic (alloc_etherdev and net_device creation and some
such). This net_device would be created by the virtio-net.ko in the
Guest Kernel.

Where is the underlying hardware on the Host getting mapped with the
virtio-net in the guest.

The device ID table simply specifies VIRTIO_ID_NET, VIRTIO_DEV_ANY_ID

The virtio-net in Guest kernel allocated virt-queue using virtnet_alloc_queues
SO the driver puts the packet into the queue and call the xmit
function which will do
virtqueue_add_outbuf() (virtio-ring.ko) which calls virtqueue_add() --
vq->notify().
It also calls virtqueue_kick() if num_added equals 2^16 -1.

virtqueue_kick calls notify function, where is the notify function defined ?

}

1. Where is the notify function defined, I only saw assignment.
2. Now once the other side ( the Host side ) is notified (need to see
exactly how ) who takes care of the packet on the HOST. How is this
packet received from a generic virtio framework mapped to a specific
Physical NIC. (The TX and RX registers of the physical hardware must
have been mapped to the virtio-net somehow to achieve this)

3. Suppose I have virtio-blk also enabled through:
-drive file=/home/gnayan/u1.img,if=virtio,format=raw

Then how are the two buffers in the virtio-ring differentiated if
belonging to block layer or network layer?

Kindly suggest.

Thanks
Nayan Gadre

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Neo Jia]

On Tue, Aug 16, 2016 at 03:50:44AM +, Tian, Kevin wrote:
> > From: Neo Jia [mailto:c...@nvidia.com]
> > Sent: Tuesday, August 16, 2016 11:46 AM
> > 
> > On Tue, Aug 16, 2016 at 12:30:25AM +, Tian, Kevin wrote:
> > > > From: Neo Jia [mailto:c...@nvidia.com]
> > > > Sent: Tuesday, August 16, 2016 3:59 AM
> > 
> > > > > >
> > > > > > For NVIDIA vGPU solution we need to know all devices assigned to a 
> > > > > > VM in
> > > > > > one shot to commit resources of all vGPUs assigned to a VM along 
> > > > > > with
> > > > > > some common resources.
> > > > >
> > > > > Kirti, can you elaborate the background about above one-shot commit
> > > > > requirement? It's hard to understand such a requirement.
> > > > >
> > > > > As I relied in another mail, I really hope start/stop become a 
> > > > > per-mdev
> > > > > attribute instead of global one, e.g.:
> > > > >
> > > > > echo "0/1" > 
> > > > > /sys/class/mdev/12345678-1234-1234-1234-123456789abc/start
> > > > >
> > > > > In many scenario the user space client may only want to talk to mdev
> > > > > instance directly, w/o need to contact its parent device. Still take
> > > > > live migration for example, I don't think Qemu wants to know parent
> > > > > device of assigned mdev instances.
> > > >
> > > > Hi Kevin,
> > > >
> > > > Having a global /sys/class/mdev/mdev_start doesn't require anybody to 
> > > > know
> > > > parent device. you can just do
> > > >
> > > > echo "mdev_UUID" > /sys/class/mdev/mdev_start
> > > >
> > > > or
> > > >
> > > > echo "mdev_UUID" > /sys/class/mdev/mdev_stop
> > > >
> > > > without knowing the parent device.
> > > >
> > >
> > > You can look at some existing sysfs example, e.g.:
> > >
> > > echo "0/1" > /sys/bus/cpu/devices/cpu1/online
> > >
> > > You may also argue why not using a global style:
> > >
> > > echo "cpu1" > /sys/bus/cpu/devices/cpu_online
> > > echo "cpu1" > /sys/bus/cpu/devices/cpu_offline
> > >
> > > There are many similar examples...
> > 
> > Hi Kevin,
> > 
> > My response above is to your question about using the global sysfs entry as 
> > you
> > don't want to have the global path because
> > 
> > "I don't think Qemu wants to know parent device of assigned mdev 
> > instances.".
> > 
> > So I just want to confirm with you that (in case you miss):
> > 
> > /sys/class/mdev/mdev_start | mdev_stop
> > 
> > doesn't require the knowledge of parent device.
> > 
> 
> Qemu is just one example, where your explanation of parent device
> makes sense but still it's not good for Qemu to populate /sys/class/mdev
> directly. Qemu is passed with the actual sysfs path of assigned mdev
> instance, so any mdev attributes touched by Qemu should be put under 
> that node (e.g. start/stop for live migration usage as I explained earlier).

Exactly, qemu is passed with the actual sysfs path.

So, QEMU doesn't touch the file /sys/class/mdev/mdev_start | mdev_stop at all.

QEMU will take the sysfs path as input:

 -device 
vfio-pci,sysfsdev=/sys/bus/mdev/devices/c0b26072-dd1b-4340-84fe-bf338c510818-0,id=vgpu0

As you are saying in live migration, QEMU needs to access "start" and "stop".  
Could you 
please share more details, such as how QEMU access the "start" and "stop" sysfs,
when and what triggers that?

Thanks,
Neo

> 

> Thanks
> Kevin

Re: [Qemu-devel] [PATCH for-2.7] slirp: Rename "struct arphdr" to "struct slirp_arphdr"

[Brad Smith]

On 08/15/16 04:24, Thomas Huth wrote:

struct arphdr is already used by the system headers on OpenBSD
and thus QEMU does not compile here anymore. Fix it by renaming
our struct to slirp_arphdr instead.

Reported-by: Brad Smith
Buglink: https://bugs.launchpad.net/qemu/+bug/1613133
Signed-off-by: Thomas Huth 


Thanks, this does fix the build.


---
 slirp/slirp.c | 10 +-
 slirp/slirp.h |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/slirp/slirp.c b/slirp/slirp.c
index 47a1652..d67eda1 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -773,10 +773,10 @@ void slirp_pollfds_poll(GArray *pollfds, int select_error)

 static void arp_input(Slirp *slirp, const uint8_t *pkt, int pkt_len)
 {
-struct arphdr *ah = (struct arphdr *)(pkt + ETH_HLEN);
-uint8_t arp_reply[max(ETH_HLEN + sizeof(struct arphdr), 64)];
+struct slirp_arphdr *ah = (struct slirp_arphdr *)(pkt + ETH_HLEN);
+uint8_t arp_reply[max(ETH_HLEN + sizeof(struct slirp_arphdr), 64)];
 struct ethhdr *reh = (struct ethhdr *)arp_reply;
-struct arphdr *rah = (struct arphdr *)(arp_reply + ETH_HLEN);
+struct slirp_arphdr *rah = (struct slirp_arphdr *)(arp_reply + ETH_HLEN);
 int ar_op;
 struct ex_list *ex_ptr;

@@ -890,9 +890,9 @@ static int if_encap4(Slirp *slirp, struct mbuf *ifm, struct 
ethhdr *eh,
 return 1;
 }
 if (!arp_table_search(slirp, iph->ip_dst.s_addr, ethaddr)) {
-uint8_t arp_req[ETH_HLEN + sizeof(struct arphdr)];
+uint8_t arp_req[ETH_HLEN + sizeof(struct slirp_arphdr)];
 struct ethhdr *reh = (struct ethhdr *)arp_req;
-struct arphdr *rah = (struct arphdr *)(arp_req + ETH_HLEN);
+struct slirp_arphdr *rah = (struct slirp_arphdr *)(arp_req + ETH_HLEN);

 if (!ifm->resolution_requested) {
 /* If the client addr is not known, send an ARP request */
diff --git a/slirp/slirp.h b/slirp/slirp.h
index 624a850..a1f3139 100644
--- a/slirp/slirp.h
+++ b/slirp/slirp.h
@@ -105,7 +105,7 @@ struct ethhdr {
 unsigned short h_proto;/* packet type ID field */
 };

-struct arphdr {
+struct slirp_arphdr {
 unsigned short ar_hrd;  /* format of hardware address */
 unsigned short ar_pro;  /* format of protocol address */
 unsigned char  ar_hln;  /* length of hardware address */
@@ -124,7 +124,7 @@ struct arphdr {
 #define ARP_TABLE_SIZE 16

 typedef struct ArpTable {
-struct arphdr table[ARP_TABLE_SIZE];
+struct slirp_arphdr table[ARP_TABLE_SIZE];
 int next_victim;
 } ArpTable;

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Tian, Kevin]

> From: Neo Jia [mailto:c...@nvidia.com]
> Sent: Tuesday, August 16, 2016 11:46 AM
> 
> On Tue, Aug 16, 2016 at 12:30:25AM +, Tian, Kevin wrote:
> > > From: Neo Jia [mailto:c...@nvidia.com]
> > > Sent: Tuesday, August 16, 2016 3:59 AM
> 
> > > > >
> > > > > For NVIDIA vGPU solution we need to know all devices assigned to a VM 
> > > > > in
> > > > > one shot to commit resources of all vGPUs assigned to a VM along with
> > > > > some common resources.
> > > >
> > > > Kirti, can you elaborate the background about above one-shot commit
> > > > requirement? It's hard to understand such a requirement.
> > > >
> > > > As I relied in another mail, I really hope start/stop become a per-mdev
> > > > attribute instead of global one, e.g.:
> > > >
> > > > echo "0/1" > /sys/class/mdev/12345678-1234-1234-1234-123456789abc/start
> > > >
> > > > In many scenario the user space client may only want to talk to mdev
> > > > instance directly, w/o need to contact its parent device. Still take
> > > > live migration for example, I don't think Qemu wants to know parent
> > > > device of assigned mdev instances.
> > >
> > > Hi Kevin,
> > >
> > > Having a global /sys/class/mdev/mdev_start doesn't require anybody to know
> > > parent device. you can just do
> > >
> > > echo "mdev_UUID" > /sys/class/mdev/mdev_start
> > >
> > > or
> > >
> > > echo "mdev_UUID" > /sys/class/mdev/mdev_stop
> > >
> > > without knowing the parent device.
> > >
> >
> > You can look at some existing sysfs example, e.g.:
> >
> > echo "0/1" > /sys/bus/cpu/devices/cpu1/online
> >
> > You may also argue why not using a global style:
> >
> > echo "cpu1" > /sys/bus/cpu/devices/cpu_online
> > echo "cpu1" > /sys/bus/cpu/devices/cpu_offline
> >
> > There are many similar examples...
> 
> Hi Kevin,
> 
> My response above is to your question about using the global sysfs entry as 
> you
> don't want to have the global path because
> 
> "I don't think Qemu wants to know parent device of assigned mdev instances.".
> 
> So I just want to confirm with you that (in case you miss):
> 
> /sys/class/mdev/mdev_start | mdev_stop
> 
> doesn't require the knowledge of parent device.
> 

Qemu is just one example, where your explanation of parent device
makes sense but still it's not good for Qemu to populate /sys/class/mdev
directly. Qemu is passed with the actual sysfs path of assigned mdev
instance, so any mdev attributes touched by Qemu should be put under 
that node (e.g. start/stop for live migration usage as I explained earlier).

Thanks
Kevin

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Neo Jia]

On Tue, Aug 16, 2016 at 12:30:25AM +, Tian, Kevin wrote:
> > From: Neo Jia [mailto:c...@nvidia.com]
> > Sent: Tuesday, August 16, 2016 3:59 AM

> > > >
> > > > For NVIDIA vGPU solution we need to know all devices assigned to a VM in
> > > > one shot to commit resources of all vGPUs assigned to a VM along with
> > > > some common resources.
> > >
> > > Kirti, can you elaborate the background about above one-shot commit
> > > requirement? It's hard to understand such a requirement.
> > >
> > > As I relied in another mail, I really hope start/stop become a per-mdev
> > > attribute instead of global one, e.g.:
> > >
> > > echo "0/1" > /sys/class/mdev/12345678-1234-1234-1234-123456789abc/start
> > >
> > > In many scenario the user space client may only want to talk to mdev
> > > instance directly, w/o need to contact its parent device. Still take
> > > live migration for example, I don't think Qemu wants to know parent
> > > device of assigned mdev instances.
> > 
> > Hi Kevin,
> > 
> > Having a global /sys/class/mdev/mdev_start doesn't require anybody to know
> > parent device. you can just do
> > 
> > echo "mdev_UUID" > /sys/class/mdev/mdev_start
> > 
> > or
> > 
> > echo "mdev_UUID" > /sys/class/mdev/mdev_stop
> > 
> > without knowing the parent device.
> > 
> 
> You can look at some existing sysfs example, e.g.:
> 
> echo "0/1" > /sys/bus/cpu/devices/cpu1/online
> 
> You may also argue why not using a global style:
> 
> echo "cpu1" > /sys/bus/cpu/devices/cpu_online
> echo "cpu1" > /sys/bus/cpu/devices/cpu_offline
> 
> There are many similar examples...

Hi Kevin,

My response above is to your question about using the global sysfs entry as you
don't want to have the global path because

"I don't think Qemu wants to know parent device of assigned mdev instances.".

So I just want to confirm with you that (in case you miss):

/sys/class/mdev/mdev_start | mdev_stop 

doesn't require the knowledge of parent device.

Thanks,
Neo

> 
> Thanks
> Kevin

Re: [Qemu-devel] [PATCH v4] docs: add cpu-hotplug.txt

[Dou Liyang]

Hi Bharata,

At 08/16/2016 11:31 AM, Bharata B Rao wrote:

On Tue, Aug 16, 2016 at 11:07:41AM +0800, Dou Liyang wrote:

This document describes how to use cpu hotplug in QEMU.

Signed-off-by: Andrew Jones 
Signed-off-by: Dou Liyang 
---
Change log v3 -> v4
  From David's advice
1. add spapr examples
2. Fix some comment
  From drew's advice
1. Fix some syntax
+
+For example, the following command-line:
+
+ qemu [...] -smp 3,maxcpus=8,sockets=2,cores=2,threads=2


This is not a valid topology on sPAPR. In the documentation, why not have
a bit more generic topology that is likely to work for most archs ?

Like -smp 4,maxcpus=8,sockets=2,cores=2,threads=2.


Yes, I got it.
I will change it and check other examples.

Thanks,
Dou

Re: [Qemu-devel] [PATCH v4] docs: add cpu-hotplug.txt

[Bharata B Rao]

On Tue, Aug 16, 2016 at 11:07:41AM +0800, Dou Liyang wrote:
> This document describes how to use cpu hotplug in QEMU.
> 
> Signed-off-by: Andrew Jones 
> Signed-off-by: Dou Liyang 
> ---
> Change log v3 -> v4
>   From David's advice
> 1. add spapr examples
> 2. Fix some comment
>   From drew's advice
> 1. Fix some syntax
> 
> Change log v2 -> v3:
>   From drew's advice:
> 1. modify the examples.
> 2. Fix some syntax.
> 
> Change log v1 -> v2:
>   From Fam's advice:
> 1. Fix some comment.
> 
> Change log v1:
>   From Igor's advice:
> 1. Remove any mentioning of apic-id from the document.
> 2. Remove the "device_del qom_path" from the CPU hot-unplug.
> 3. Fix some comment.
> 
>  docs/cpu-hotplug.txt | 132 
> +++
>  1 file changed, 132 insertions(+)
>  create mode 100644 docs/cpu-hotplug.txt
> 
> diff --git a/docs/cpu-hotplug.txt b/docs/cpu-hotplug.txt
> new file mode 100644
> index 000..0c1bfe9
> --- /dev/null
> +++ b/docs/cpu-hotplug.txt
> @@ -0,0 +1,132 @@
> +QEMU CPU hotplug
> +
> +
> +This document explains how to use the CPU hotplug feature in QEMU,
> +which regards the CPU as a device, using -device/device_add and
> +device_del.
> +
> +QEMU support was merged for 2.7.
> +
> +Guest support is required for CPU hotplug to work.
> +
> +CPU hot-plug
> +
> +
> +In order to be able to hotplug CPUs, QEMU has to be told the maximum
> +number of CPUs which the guest can have. This is done at startup time
> +by means of the -smp command-line option, which has the following
> +format:
> +
> + -smp [cpus=]n[,maxcpus=cpus][,cores=cores][,threads=threads]
> + [,sockets=sockets]
> +
> +Where,
> +
> + - "cpus"sets the number of CPUs to 'n' [default=1].
> + - "maxcpus" sets the maximum number of CPUs, including offline VCPUs
> +   for hotplug.
> + - "sockets" sets the number of discrete sockets in the system.
> + - "cores"   sets the number of CPU cores on one socket.
> + - "threads" sets the number of threads on one CPU core.
> +
> +For example, the following command-line:
> +
> + qemu [...] -smp 3,maxcpus=8,sockets=2,cores=2,threads=2

This is not a valid topology on sPAPR. In the documentation, why not have
a bit more generic topology that is likely to work for most archs ?

Like -smp 4,maxcpus=8,sockets=2,cores=2,threads=2.

Regards,
Bharata.

[Qemu-devel] [PATCH v4] docs: add cpu-hotplug.txt

[Dou Liyang]

This document describes how to use cpu hotplug in QEMU.

Signed-off-by: Andrew Jones 
Signed-off-by: Dou Liyang 
---
Change log v3 -> v4
  From David's advice
1. add spapr examples
2. Fix some comment
  From drew's advice
1. Fix some syntax

Change log v2 -> v3:
  From drew's advice:
1. modify the examples.
2. Fix some syntax.

Change log v1 -> v2:
  From Fam's advice:
1. Fix some comment.

Change log v1:
  From Igor's advice:
1. Remove any mentioning of apic-id from the document.
2. Remove the "device_del qom_path" from the CPU hot-unplug.
3. Fix some comment.

 docs/cpu-hotplug.txt | 132 +++
 1 file changed, 132 insertions(+)
 create mode 100644 docs/cpu-hotplug.txt

diff --git a/docs/cpu-hotplug.txt b/docs/cpu-hotplug.txt
new file mode 100644
index 000..0c1bfe9
--- /dev/null
+++ b/docs/cpu-hotplug.txt
@@ -0,0 +1,132 @@
+QEMU CPU hotplug
+
+
+This document explains how to use the CPU hotplug feature in QEMU,
+which regards the CPU as a device, using -device/device_add and
+device_del.
+
+QEMU support was merged for 2.7.
+
+Guest support is required for CPU hotplug to work.
+
+CPU hot-plug
+
+
+In order to be able to hotplug CPUs, QEMU has to be told the maximum
+number of CPUs which the guest can have. This is done at startup time
+by means of the -smp command-line option, which has the following
+format:
+
+ -smp [cpus=]n[,maxcpus=cpus][,cores=cores][,threads=threads]
+   [,sockets=sockets]
+
+Where,
+
+ - "cpus"sets the number of CPUs to 'n' [default=1].
+ - "maxcpus" sets the maximum number of CPUs, including offline VCPUs
+   for hotplug.
+ - "sockets" sets the number of discrete sockets in the system.
+ - "cores"   sets the number of CPU cores on one socket.
+ - "threads" sets the number of threads on one CPU core.
+
+For example, the following command-line:
+
+ qemu [...] -smp 3,maxcpus=8,sockets=2,cores=2,threads=2
+
+creates a guest with 3 VCPUs and supports up to 8 VCPUs. The CPU
+topology is sockets (2) * cores (2) * threads (2) and can't be
+greater than maxcpus. When the guest finishes loading, the guest
+will see 3 VCPUs. More on this below.
+
+Query available CPU objects
+---
+
+To add a VCPUs, it must be identified by socket-id, core-id, and/or
+thread-id parameters.
+
+Before adding the VCPUs, we should know those topology parameters,
+so that we can find the available location (socket,core,thread) for
+a new VCPU.
+
+Using the corresponding HMP command "info hotpluggable-cpus" to obtain
+them.
+
+For example, the following command-line:
+
+  (qemu) info hotpluggable-cpus
+
+lists the hotpluggable CPUs including "CPUInstance Properties" for
+hotplugging. Such as this:
+
+  ...
+  type: "qemu64-x86_64-cpu"
+  vcpus_count: "1"
+  CPUInstance Properties:
+socket-id: "0"
+core-id: "1"
+thread-id: "0"
+  ...
+
+Or
+
+  ...
+  type: "POWER7_v2.3-spapr-cpu-core"
+  vcpus_count: "1"
+  CPUInstance Properties:
+core-id: "2"
+  ...
+
+Different platforms may have different "CPUInstance Properties".
+
+Hotplug CPUs
+
+
+A monitor command can be used to hotplug CPUs:
+
+ - "device_add": creates a CPU device and inserts it into the
+   specific location.
+
+For example, the following command adds a VCPU, which has the id cpu1,
+to a specific location in the topology (socket=0,core=1,thread=1):
+
+  (qemu) device_add qemu64-x86_64-cpu,id=cpu1,socket-id=0,core-id=1,thread-id=1
+
+Where,
+
+ - "qemu64-x86_64-cpu" is the CPU model.
+ - "id" is the unique identifier in the device set.
+ - "socket-id/core-id/thread-id" represent the designated location,
+   which is obtained form the above possible list of CPUs.
+
+It's also possible to start a guest with a cpu cold-plugged into a
+specific location (socket,core,thread).
+
+In the following command line example, a guest which has 3 VCPUs is
+created:
+
+ qemu  [...] -smp 1,maxcpus=8,sockets=2,cores=2,threads=2 \
+   -device qemu64-x86_64-cpu,id=cpu1,socket-id=1, \
+   core-id=1,thread-id=0 \
+   -device qemu64-x86_64-cpu,id=cpu2,socket-id=1, \
+   core-id=1,thread-id=1 \
+
+Two VCPUs are cold-plugged by "-device" parameter, which are in the
+same socket and core, but with different thread-ids. After that, the
+guest has an additional five VCPUs to be hot-plugged when needed.
+
+CPU hot-unplug
+--
+
+In order to be able to hot unplug a CPU device, QEMU removes CPU
+devices by using the ids which were assigned when hotplugging the
+CPU device.
+
+A monitor command can be used to hot unplug CPUs:
+
+ - "device_del": deletes a CPU device
+
+For example, assuming that the CPU device with id "cpu1" exists,
+then the following command tries to remove it.
+
+  (qemu) device_del cpu1
+
-- 
2.5.5

[Qemu-devel] enhancements to the open firmware video driver

[Programmingkid]

I thought of a way for the video driver you made to be expandable without 
having to be recompiled. The user can specify additions resolutions like this:

-prom-env "resolutions=1200x700,1280x600,1440x700"

The video driver can then look in the /options node and use its resolutions 
property to retrieve the additional resolutions. These resolutions can then be 
made available to the guest.

Re: [Qemu-devel] [PATCH 3/3] ppc/pnv: add a PowerNVCPUCore object

[David Gibson]

On Fri, Aug 05, 2016 at 11:15:37AM +0200, Cédric Le Goater wrote:
> This is largy inspired by sPAPRCPUCore with some simplification, no
> hotplug for instance. But the differences are small and the objects
> could possibly be merged.
> 
> A set of PowerNVCPUCore objects is added to the PnvChip and the device
> tree is populated looping on these cores. Core ids in the device tree
> are still a little fuzy. To be checked.

So, it's not immediately obvious to me if you want an actual core
object.  You could potentially create the actual vcpu objects directly
from the chip object.  That assumes that any hotplug will only be at
chip granularity, not core granularity, but I'm guessing that's the
case anyway.

That said, if having the intermediate core object is helpful, you're
certainly free to have it.

> Signed-off-by: Cédric Le Goater 
> ---
>  hw/ppc/Makefile.objs  |   2 +-
>  hw/ppc/pnv.c  | 160 ++-
>  hw/ppc/pnv_core.c | 171 
> ++
>  include/hw/ppc/pnv.h  |   7 ++
>  include/hw/ppc/pnv_core.h |  47 +
>  5 files changed, 383 insertions(+), 4 deletions(-)
>  create mode 100644 hw/ppc/pnv_core.c
>  create mode 100644 include/hw/ppc/pnv_core.h
> 
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index 8105db7d5600..f8c7d1db9ade 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -6,7 +6,7 @@ obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o 
> spapr_rtas.o
>  obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o spapr_rng.o
>  obj-$(CONFIG_PSERIES) += spapr_cpu_core.o
>  # IBM PowerNV
> -obj-$(CONFIG_POWERNV) += pnv.o
> +obj-$(CONFIG_POWERNV) += pnv.o pnv_core.o
>  ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
>  obj-y += spapr_pci_vfio.o
>  endif
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index a680780e9dea..1219493c7218 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -35,6 +35,7 @@
>  #include "hw/ppc/fdt.h"
>  #include "hw/ppc/ppc.h"
>  #include "hw/ppc/pnv.h"
> +#include "hw/ppc/pnv_core.h"
>  #include "hw/loader.h"
>  #include "exec/address-spaces.h"
>  #include "qemu/cutils.h"
> @@ -112,6 +113,114 @@ static int powernv_populate_memory(void *fdt)
>  return 0;
>  }
>  
> +static void powernv_create_core_node(void *fdt, CPUState *cs, uint32_t 
> chip_id)
> +{
> +PowerPCCPU *cpu = POWERPC_CPU(cs);
> +int smt_threads = ppc_get_compat_smt_threads(cpu);
> +CPUPPCState *env = >env;
> +DeviceClass *dc = DEVICE_GET_CLASS(cs);
> +PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cs);
> +uint32_t servers_prop[smt_threads];
> +uint32_t gservers_prop[smt_threads * 2];
> +int i, index = ppc_get_vcpu_dt_id(cpu);
> +uint32_t segs[] = {cpu_to_be32(28), cpu_to_be32(40),
> +   0x, 0x};
> +uint32_t tbfreq = PNV_TIMEBASE_FREQ;
> +uint32_t cpufreq = 10;
> +uint32_t page_sizes_prop[64];
> +size_t page_sizes_prop_size;
> +char *nodename;
> +
> +nodename = g_strdup_printf("%s@%x", dc->fw_name, index);
> +
> +_FDT((fdt_begin_node(fdt, nodename)));
> +
> +g_free(nodename);
> +
> +_FDT((fdt_property_cell(fdt, "reg", index)));
> +_FDT((fdt_property_string(fdt, "device_type", "cpu")));

The handling of dt_id is going to collide with cleanups I want to do
in this area (for spapr and the ppc cpu core).  Not sure there's a lot
you can do to avoid that at this stage.

> +_FDT((fdt_property_cell(fdt, "cpu-version", env->spr[SPR_PVR])));
> +_FDT((fdt_property_cell(fdt, "d-cache-block-size",
> +env->dcache_line_size)));
> +_FDT((fdt_property_cell(fdt, "d-cache-line-size",
> +env->dcache_line_size)));
> +_FDT((fdt_property_cell(fdt, "i-cache-block-size",
> +env->icache_line_size)));
> +_FDT((fdt_property_cell(fdt, "i-cache-line-size",
> +env->icache_line_size)));
> +
> +if (pcc->l1_dcache_size) {
> +_FDT((fdt_property_cell(fdt, "d-cache-size", pcc->l1_dcache_size)));
> +} else {
> +error_report("Warning: Unknown L1 dcache size for cpu");
> +}
> +if (pcc->l1_icache_size) {
> +_FDT((fdt_property_cell(fdt, "i-cache-size", pcc->l1_icache_size)));
> +} else {
> +error_report("Warning: Unknown L1 icache size for cpu");
> +}
> +
> +_FDT((fdt_property_cell(fdt, "timebase-frequency", tbfreq)));
> +_FDT((fdt_property_cell(fdt, "clock-frequency", cpufreq)));
> +_FDT((fdt_property_cell(fdt, "ibm,slb-size", env->slb_nr)));
> +_FDT((fdt_property_string(fdt, "status", "okay")));
> +_FDT((fdt_property(fdt, "64-bit", NULL, 0)));
> +
> +if (env->spr_cb[SPR_PURR].oea_read) {
> +_FDT((fdt_property(fdt, "ibm,purr", NULL, 0)));
> +}
> +
> +if (env->mmu_model & POWERPC_MMU_1TSEG) {
> +_FDT((fdt_property(fdt, 

Re: [Qemu-devel] [PATCH 2/3] ppc/pnv: add a PnvChip object

[David Gibson]

On Fri, Aug 05, 2016 at 11:15:36AM +0200, Cédric Le Goater wrote:
> This is is an abstraction of a P8 chip which is a set of cores plus
> other 'units', like the pervasive unit, the interrupt controller, the
> memory controller, the on-chip microcontroller, etc. The whole can be
> seen as a socket.
> 
> We start with an empty PnvChip which we will grow in the subsequent
> patches with controllers required to run the system.
> 
> Signed-off-by: Cédric Le Goater 
> ---
>  hw/ppc/pnv.c | 47 +++
>  include/hw/ppc/pnv.h | 15 +++
>  2 files changed, 62 insertions(+)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 3bb6a240c25b..a680780e9dea 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -185,6 +185,7 @@ static void ppc_powernv_init(MachineState *machine)
>  sPowerNVMachineState *pnv = POWERNV_MACHINE(machine);
>  long fw_size;
>  char *filename;
> +int i;
>  
>  if (ram_size < (1 * G_BYTE)) {
>  error_report("Warning: skiboot may not work with < 1GB of RAM");
> @@ -236,6 +237,23 @@ static void ppc_powernv_init(MachineState *machine)
>  pnv->initrd_base = 0;
>  pnv->initrd_size = 0;
>  }
> +
> +/* Create PowerNV chips
> + *
> + * FIXME: We should decide how many chips to create based on
> + * #cores and Venice vs. Murano vs. Naples chip type etc..., for
> + * now, just create one chip, with all the cores.
> + */
> +pnv->num_chips = 1;
> +
> +pnv->chips = g_new0(PnvChip, pnv->num_chips);
> +for (i = 0; i < pnv->num_chips; i++) {
> +PnvChip *chip = >chips[i];
> +
> +object_initialize(chip, sizeof(*chip), TYPE_PNV_CHIP);

I think you'd be better off having an array of pointers, each one you
allocate with object_new() rather than doing an explicit g_new0() for
the whole array then using object_initialize().

For one thing, if certain chip subtypes need to allocate more space
for their instance, then this approach will break, whereas
object_new() will get that right.

> +object_property_set_int(OBJECT(chip), i, "chip-id", _abort);
> +object_property_set_bool(OBJECT(chip), true, "realized", 
> _abort);
> +}
>  }
>  
>  static void powernv_machine_class_init(ObjectClass *oc, void *data)
> @@ -274,10 +292,39 @@ static const TypeInfo powernv_machine_2_8_info = {
>  .class_init= powernv_machine_2_8_class_init,
>  };
>  
> +
> +static void pnv_chip_realize(DeviceState *dev, Error **errp)
> +{
> +;
> +}
> +
> +static Property pnv_chip_properties[] = {
> +DEFINE_PROP_UINT32("chip-id", PnvChip, chip_id, 0),
> +DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void pnv_chip_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +
> +dc->realize = pnv_chip_realize;
> +dc->props = pnv_chip_properties;
> +dc->desc = "PowerNV Chip";
> + }
> +
> +static const TypeInfo pnv_chip_info = {
> +.name  = TYPE_PNV_CHIP,
> +.parent= TYPE_SYS_BUS_DEVICE,
> +.instance_size = sizeof(PnvChip),
> +.class_init= pnv_chip_class_init,
> +};
> +
> +
>  static void powernv_machine_register_types(void)
>  {
>  type_register_static(_machine_info);
>  type_register_static(_machine_2_8_info);
> +type_register_static(_chip_info);
>  }
>  
>  type_init(powernv_machine_register_types)
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index 2990f691672d..6907dc9e5c3d 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -20,6 +20,18 @@
>  #define _PPC_PNV_H
>  
>  #include "hw/boards.h"
> +#include "hw/sysbus.h"
> +
> +#define TYPE_PNV_CHIP "powernv-chip"
> +#define PNV_CHIP(obj) OBJECT_CHECK(PnvChip, (obj), TYPE_PNV_CHIP)
> +
> +typedef struct PnvChip {
> +/*< private >*/
> +SysBusDevice parent_obj;
> +
> +/*< public >*/
> +uint32_t chip_id;
> +} PnvChip;
>  
>  #define TYPE_POWERNV_MACHINE  "powernv-machine"
>  #define POWERNV_MACHINE(obj) \
> @@ -31,6 +43,9 @@ typedef struct sPowerNVMachineState {
>  
>  uint32_t initrd_base;
>  long initrd_size;
> +
> +uint32_t  num_chips;
> +PnvChip   *chips;
>  } sPowerNVMachineState;
>  
>  #endif /* _PPC_PNV_H */

-- 
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 2/3] ppc/pnv: add a PnvChip object

[David Gibson]

On Sat, Aug 06, 2016 at 08:43:21AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2016-08-05 at 18:48 +0200, Cédric Le Goater wrote:
> > The core initialization should be ok but building the device 
> > tree might be a bit of a burden if we have to 'cast' in the chip 
> > type we need. We will see.
> 
> We don't cast, we use a method.

Right.  You can have a look at the sPAPR VIO stuff for an example
where we use a method in the individual devices to do the device
specific fdt construction.

> 
> > So what would be the big differences with what we have today ?   
> 
> The XSCOM controller has a different address decoding scheme, so
> we'll have two variants and a base class there. The number and
> location of functional units changes, so we'll probably need to make
> them properties or something, the core XSCOM addressing is completely
> different, we use PHB4 rather than PHB3, etc...
> 
> (Note that for PHB we should probably rename PHB3 to PnvPhb with a
> subclass as well as there is a lot in common between the two, though
> the PBCQ bit is quite different).
> 

-- 
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

[Qemu-devel] [PATCH v4] ui/cocoa.m: Make a better about dialog

[Programmingkid]

The about dialog in QEMU on Mac OS X is very plain and unhelpful. This patch
makes the about dialog look a lot better and have some descriptive information
on what version of QEMU the user is running.

Signed-off-by: John Arbuckle 
---
version 4 changes:
Moved qemu-version.h include above Carbon.h include.
Replaced NSScaleToFit with NSImageScaleProportionallyUpOrDown.
Removed space between QEMU_VERSION and QEMU_PKGVERSION text.
Used QEMU_COPYRIGHT in place of text copyright.

version 3 changes:
Removed buffer related code

version 2 changes:
Added QEMU version to the version label

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

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 36c6bf0..52d9c54 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -33,6 +33,7 @@
 #include "sysemu/sysemu.h"
 #include "qmp-commands.h"
 #include "sysemu/blockdev.h"
+#include "qemu-version.h"
 #include 
 
 #ifndef MAC_OS_X_VERSION_10_5
@@ -63,7 +64,7 @@ typedef struct {
 int bitsPerPixel;
 } QEMUScreen;
 
-NSWindow *normalWindow;
+NSWindow *normalWindow, *about_window;
 static DisplayChangeListener *dcl;
 static int last_buttons;
 
@@ -670,7 +671,9 @@ QemuCocoaView *cocoaView;
 case NSLeftMouseUp:
 mouse_event = true;
 if (!isMouseGrabbed && [self screenContainsPoint:p]) {
-[self grabMouse];
+if([[self window] isKeyWindow]) {
+[self grabMouse];
+}
 }
 break;
 case NSRightMouseUp:
@@ -824,6 +827,8 @@ QemuCocoaView *cocoaView;
 - (void)changeDeviceMedia:(id)sender;
 - (BOOL)verifyQuit;
 - (void)openDocumentation:(NSString *)filename;
+- (IBAction) do_about_menu_item: (id) sender;
+- (void)make_about_window;
 @end
 
 @implementation QemuCocoaAppController
@@ -876,6 +881,7 @@ QemuCocoaView *cocoaView;
 supportedImageFileTypes = [NSArray arrayWithObjects: @"img", @"iso", 
@"dmg",
  @"qcow", @"qcow2", @"cloop", @"vmdk", @"cdr",
   nil];
+[self make_about_window];
 }
 return self;
 }
@@ -1138,6 +1144,101 @@ QemuCocoaView *cocoaView;
 }
 }
 
+/* The action method for the About menu item */
+- (IBAction) do_about_menu_item: (id) sender
+{
+[about_window makeKeyAndOrderFront: nil];
+}
+
+/* Create and display the about dialog */
+- (void)make_about_window
+{
+/* Make the window */
+int x = 0, y = 0, about_width = 400, about_height = 200;
+NSRect window_rect = NSMakeRect(x, y, about_width, about_height);
+about_window = [[NSWindow alloc] initWithContentRect:window_rect
+styleMask:NSTitledWindowMask | NSClosableWindowMask |
+NSMiniaturizableWindowMask
+backing:NSBackingStoreBuffered
+defer:NO];
+[about_window setTitle: @"About"];
+[about_window setReleasedWhenClosed: NO];
+[about_window center];
+NSView *superView = [about_window contentView];
+
+/* Create the dimensions of the picture */
+int picture_width = 80, picture_height = 80;
+x = (about_width - picture_width)/2;
+y = about_height - picture_height - 10;
+NSRect picture_rect = NSMakeRect(x, y, picture_width, picture_height);
+
+/* Get the path to the QEMU binary */
+NSString *binary_name = [NSString stringWithCString: gArgv[0]
+  encoding: NSASCIIStringEncoding];
+binary_name = [binary_name lastPathComponent];
+NSString *program_path = [[NSString alloc] initWithFormat: @"%@/%@",
+[[NSBundle mainBundle] bundlePath], binary_name];
+
+/* Make the picture of QEMU */
+NSImageView *picture_view = [[NSImageView alloc] initWithFrame:
+ picture_rect];
+NSImage *qemu_image = [[NSWorkspace sharedWorkspace] iconForFile:
+ program_path];
+[picture_view setImage: qemu_image];
+[picture_view setImageScaling: NSImageScaleProportionallyUpOrDown];
+[superView addSubview: picture_view];
+
+/* Make the name label */
+x = 0;
+y = y - 25;
+int name_width = about_width, name_height = 20;
+NSRect name_rect = NSMakeRect(x, y, name_width, name_height);
+NSTextField *name_label = [[NSTextField alloc] initWithFrame: name_rect];
+[name_label setEditable: NO];
+[name_label setBezeled: NO];
+[name_label setDrawsBackground: NO];
+[name_label setAlignment: NSCenterTextAlignment];
+NSString *qemu_name = [[NSString alloc] initWithCString: gArgv[0]
+encoding: NSASCIIStringEncoding];
+qemu_name = [qemu_name lastPathComponent];
+[name_label setStringValue: qemu_name];
+[superView addSubview: name_label];
+
+/* Set the version label's attributes */
+x = 0;
+y = 50;
+int 

Re: [Qemu-devel] [PATCH 1/3] ppc/pnv: add skeleton PowerNV platform

[David Gibson]

On Fri, Aug 05, 2016 at 11:15:35AM +0200, Cédric Le Goater wrote:
> From: Benjamin Herrenschmidt 
> 
> The goal is to emulate a PowerNV system at the level of the skiboot
> firmware, which loads the OS and provides some runtime services. Power
> Systems have a lower firmware (HostBoot) that does low level system
> initialization, like DRAM training. This is beyond the scope of what
> qemu will address in a PowerNV guest.
> 
> No devices yet, not even an interrupt controller. Just to get started,
> some RAM to load the skiboot firmware, the kernel and initrd. The
> device tree is fully created in the machine reset op.
> 
> Signed-off-by: Benjamin Herrenschmidt 
> [clg: - updated for qemu-2.7
>   - replaced fprintf by error_report
>   - used a common definition of _FDT macro
>   - removed VMStateDescription as migration is not yet supported
>   - added IBM Copyright statements
>   - reworked kernel_filename handling
>   - merged PnvSystem and sPowerNVMachineState
>   - removed PHANDLE_XICP
>   - added ppc_create_page_sizes_prop helper
>   - removed nmi support
>   - removed kvm support
>   - updated powernv machine to version 2.8
>   - removed chips and cpus, They will be provided in another patches
>   - added a machine reset routine to initialize the device tree (also)
>   - french has a squelette and english a skeleton.
>   - improved commit log.
>   - reworked prototypes parameters
>   - added a check on the ram size (thanks to Michael Ellerman)
>   - fixed chip-id cell
>   - and then, I got lost with the changes.
> ]
> Signed-off-by: Cédric Le Goater 
> ---
>  default-configs/ppc64-softmmu.mak |   1 +
>  hw/ppc/Makefile.objs  |   2 +
>  hw/ppc/pnv.c  | 283 
> ++
>  include/hw/ppc/pnv.h  |  36 +
>  4 files changed, 322 insertions(+)
>  create mode 100644 hw/ppc/pnv.c
>  create mode 100644 include/hw/ppc/pnv.h
> 
> diff --git a/default-configs/ppc64-softmmu.mak 
> b/default-configs/ppc64-softmmu.mak
> index c4be59f638ed..516a6e25aba3 100644
> --- a/default-configs/ppc64-softmmu.mak
> +++ b/default-configs/ppc64-softmmu.mak
> @@ -40,6 +40,7 @@ CONFIG_I8259=y
>  CONFIG_XILINX=y
>  CONFIG_XILINX_ETHLITE=y
>  CONFIG_PSERIES=y
> +CONFIG_POWERNV=y
>  CONFIG_PREP=y
>  CONFIG_MAC=y
>  CONFIG_E500=y
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index 99a0d4e581bf..8105db7d5600 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -5,6 +5,8 @@ obj-$(CONFIG_PSERIES) += spapr.o spapr_vio.o spapr_events.o
>  obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
>  obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o spapr_rng.o
>  obj-$(CONFIG_PSERIES) += spapr_cpu_core.o
> +# IBM PowerNV
> +obj-$(CONFIG_POWERNV) += pnv.o
>  ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
>  obj-y += spapr_pci_vfio.o
>  endif
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> new file mode 100644
> index ..3bb6a240c25b
> --- /dev/null
> +++ b/hw/ppc/pnv.c
> @@ -0,0 +1,283 @@
> +/*
> + * QEMU PowerPC PowerNV model
> + *
> + * Copyright (c) 2004-2007 Fabrice Bellard
> + * Copyright (c) 2007 Jocelyn Mayer
> + * Copyright (c) 2010 David Gibson, IBM Corporation.
> + * Copyright (c) 2014-2016 BenH, IBM Corporation.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to 
> deal
> + * in the Software without restriction, including without limitation the 
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + *
> + */
> +#include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "sysemu/sysemu.h"
> +#include "sysemu/numa.h"
> +#include "hw/hw.h"
> +#include "target-ppc/cpu.h"
> +#include "qemu/log.h"
> +#include "hw/ppc/fdt.h"
> +#include "hw/ppc/ppc.h"
> +#include "hw/ppc/pnv.h"
> +#include "hw/loader.h"
> +#include "exec/address-spaces.h"
> +#include "qemu/cutils.h"
> +
> +#include 
> +
> +#define FDT_ADDR

Re: [Qemu-devel] [PATCH v9 00/11] Provide a QOM-based authorization API

[Fam Zheng]

On Mon, 08/15 14:07, Daniel P. Berrange wrote:
> 
> [snip]
> 
> This and all the other errors reported here are all *pre-existing*
> problems. It seems this bot does not have git rename detection turned
> on so is reporting all these problems in file-renames my patches did.
> 
> The bot needs to have something like this added to its $HOME/.gitconfig:
> 
>   [diff]
>   renamelimit=1000
>   renames=True

Done!

Fam

Re: [Qemu-devel] [PATCH v10 00/11] Provide a QOM-based authorization API

[Fam Zheng]

On Mon, 08/15 07:46, no-re...@ec2-52-6-146-230.compute-1.amazonaws.com wrote:
> /tmp/qemu-test/src/util/authz-pam.c:26:32: warning: security/pam_appl.h: No 
> such file or directory

Hi Daniel,

I think there is an unfortunate CONFIG_ var collision you probably want to
avoid:

$ git grep CONFIG_PAM
configure:echo "CONFIG_PAM=y" >> $config_host_mak
default-configs/i386-softmmu.mak:CONFIG_PAM=y
default-configs/x86_64-softmmu.mak:CONFIG_PAM=y
util/Makefile.objs:$(warning $(CONFIG_PAM))
util/Makefile.objs:util-qom-obj-$(CONFIG_PAM) += authz-pam.o

Fam

Re: [Qemu-devel] ARM MCU Target Structure Question

[Carl Allendorph]

On Mon, Aug 15, 2016 at 3:18 AM, Peter Maydell 
wrote:

> This broadly matches the directory arrangement principles used
> by the Linux kernel sources, which is where we've borrowed it from.
>

Ok - I'll pursue the current directory structure.

​Thanks,​
​~C​

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Tian, Kevin]

> From: Neo Jia [mailto:c...@nvidia.com]
> Sent: Tuesday, August 16, 2016 7:24 AM
> 
> > > >
> > > > > >
> > > > > > For NVIDIA vGPU solution we need to know all devices assigned to a 
> > > > > > VM in
> > > > > > one shot to commit resources of all vGPUs assigned to a VM along 
> > > > > > with
> > > > > > some common resources.
> > > > >
> > > > > Kirti, can you elaborate the background about above one-shot commit
> > > > > requirement? It's hard to understand such a requirement.
> > > >
> > > > Agree, I know NVIDIA isn't planning to support hotplug initially, but
> > > > this seems like we're precluding hotplug from the design.  I don't
> > > > understand what's driving this one-shot requirement.
> > >
> > > Hi Alex,
> > >
> > > The requirement here is based on how our internal vGPU device model 
> > > designed and
> > > with this we are able to pre-allocate resources required for multiple 
> > > virtual
> > > devices within same domain.
> > >
> > > And I don't think this syntax will stop us from supporting hotplug at all.
> > >
> > > For example, you can always create a virtual mdev and then do
> > >
> > > echo "mdev_UUID" > /sys/class/mdev/mdev_start
> > >
> > > then use QEMU monitor to add the device for hotplug.
> >
> > Hi Neo,
> >
> > I'm still not understanding the advantage you get from the "one-shot"
> > approach then if we can always add more mdevs by starting them later.
> > Are the hotplug mdevs somehow less capable than the initial set of
> > mdevs added in a single shot?  If the initial set is allocated
> > from the "same domain", does that give them some sort of hardware
> > locality/resource benefit?  Thanks,
> 
> Hi Alex,
> 
> At least we will not able to guarantee some special hardware resource for the
> hotplug devices.
> 
> So from our point of view, we also have dedicated internal SW entity to 
> manage all
> virtual devices for each "domain/virtual machine", and such SW entity will be 
> created
> at virtual device start time.
> 
> This is why we need to do this in one-shot to support multiple virtual device
> per VM case.
> 

Is pre-allocation of special hardware resource done one-time for all mdev 
instances?
Can it be done one-by-one as long as mdev is started early before VM is 
launched?

If such one-shot requirement is really required, it would be cleaner to me to
introduce a mdev group concept, so mdev instances with one-short start 
requirements can be put under a mdev group. Then you can do one-shot start
by:

echo "0/1" > /sys/class/mdev/group/0/start

Thanks
Kevin

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Tian, Kevin]

> From: Neo Jia [mailto:c...@nvidia.com]
> Sent: Tuesday, August 16, 2016 3:59 AM
> 
> On Mon, Aug 15, 2016 at 09:38:52AM +, Tian, Kevin wrote:
> > > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > > Sent: Saturday, August 13, 2016 8:37 AM
> > >
> > >
> > >
> > > On 8/13/2016 2:46 AM, Alex Williamson wrote:
> > > > On Sat, 13 Aug 2016 00:14:39 +0530
> > > > Kirti Wankhede  wrote:
> > > >
> > > >> On 8/10/2016 12:30 AM, Alex Williamson wrote:
> > > >>> On Thu, 4 Aug 2016 00:33:51 +0530
> > > >>> Kirti Wankhede  wrote:
> > > >>>
> > > >>> This is used later by mdev_device_start() and mdev_device_stop() to 
> > > >>> get
> > > >>> the parent_device so it can call the start and stop ops callbacks
> > > >>> respectively.  That seems to imply that all of instances for a given
> > > >>> uuid come from the same parent_device.  Where is that enforced?  I'm
> > > >>> still having a hard time buying into the uuid+instance plan when it
> > > >>> seems like each mdev_device should have an actual unique uuid.
> > > >>> Userspace tools can figure out which uuids to start for a given user, 
> > > >>> I
> > > >>> don't see much value in collecting them to instances within a uuid.
> > > >>>
> > > >>
> > > >> Initially we started discussion with VM_UUID+instance suggestion, where
> > > >> instance was introduced to support multiple devices in a VM.
> > > >
> > > > The instance number was never required in order to support multiple
> > > > devices in a VM, IIRC this UUID+instance scheme was to appease NVIDIA
> > > > management tools which wanted to re-use the VM UUID by creating vGPU
> > > > devices with that same UUID and therefore associate udev events to a
> > > > given VM.  Only then does an instance number become necessary since the
> > > > UUID needs to be static for a vGPUs within a VM.  This has always felt
> > > > like a very dodgy solution when we should probably just be querying
> > > > libvirt to give us a device to VM association.
> >
> > Agree with Alex here. We'd better not assume that UUID will be a VM_UUID
> > for mdev in the basic design. It's bound to NVIDIA management stack too 
> > tightly.
> >
> > I'm OK to give enough flexibility for various upper level management stacks,
> > e.g. instead of $UUID+INDEX style, would $UUID+STRING provide a better
> > option where either UUID or STRING could be optional? Upper management
> > stack can choose its own policy to identify a mdev:
> >
> > a) $UUID only, so each mdev is allocated with a unique UUID
> > b) STRING only, which could be an index (0, 1, 2, ...), or any combination
> > (vgpu0, vgpu1, etc.)
> > c) $UUID+STRING, where UUID could be a VM UUID, and STRING could be
> > a numeric index
> >
> > > >
> > > >> 'mdev_create' creates device and 'mdev_start' is to commit resources of
> > > >> all instances of similar devices assigned to VM.
> > > >>
> > > >> For example, to create 2 devices:
> > > >> # echo "$UUID:0:params" > /sys/devices/../mdev_create
> > > >> # echo "$UUID:1:params" > /sys/devices/../mdev_create
> > > >>
> > > >> "$UUID-0" and "$UUID-1" devices are created.
> > > >>
> > > >> Commit resources for above devices with single 'mdev_start':
> > > >> # echo "$UUID" > /sys/class/mdev/mdev_start
> > > >>
> > > >> Considering $UUID to be a unique UUID of a device, we don't need
> > > >> 'instance', so 'mdev_create' would look like:
> > > >>
> > > >> # echo "$UUID1:params" > /sys/devices/../mdev_create
> > > >> # echo "$UUID2:params" > /sys/devices/../mdev_create
> > > >>
> > > >> where $UUID1 and $UUID2 would be mdev device's unique UUID and 'params'
> > > >> would be vendor specific parameters.
> > > >>
> > > >> Device nodes would be created as "$UUID1" and "$UUID"
> > > >>
> > > >> Then 'mdev_start' would be:
> > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_start
> > > >>
> > > >> Similarly 'mdev_stop' and 'mdev_destroy' would be:
> > > >>
> > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_stop
> > > >
> > > > I'm not sure a comma separated list makes sense here, for both
> > > > simplicity in the kernel and more fine grained error reporting, we
> > > > probably want to start/stop them individually.  Actually, why is it
> > > > that we can't use the mediated device being opened and released to
> > > > automatically signal to the backend vendor driver to commit and release
> > > > resources? I don't fully understand why userspace needs this interface.
> >
> > There is a meaningful use of start/stop interface, as required in live
> > migration support. Such interface allows vendor driver to quiescent
> > mdev activity on source device before mdev hardware state is snapshot,
> > and then resume mdev activity on dest device after its state is recovered.
> > Intel has implemented experimental live migration support in KVMGT (soon
> > to release), based on above two interfaces (plus another two to get/set
> > mdev state).
> >
> > > >
> > >
> > > For NVIDIA vGPU solution we need to know all 

[Qemu-devel] [PATCH 0/2] Bitmap for recovery of postcopy migration from n/w failure

[Md Haris Iqbal]

A new bitmap to keep in track the pages that were lost in case there was a
network failure during postcopy.
The bitmap is used to req for those lost pages towards the end of migration.

Md Haris Iqbal (2):
  Migration: New bitmap for postcopy migration failure
  Migration: Request lost pages (due to n/w failure) from source

 include/migration/migration.h | 10 +
 migration/migration.c | 10 -
 migration/postcopy-ram.c  |  2 +-
 migration/ram.c   | 98 ++-
 migration/savevm.c| 19 +
 5 files changed, 135 insertions(+), 4 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH 2/2] Migration: Request lost pages (due to n/w failure) from source

[Md Haris Iqbal]

Signed-off-by: Md Haris Iqbal 
---
 include/migration/migration.h |  7 +++
 migration/migration.c |  2 ++
 migration/ram.c   | 35 +++
 migration/savevm.c| 19 +++
 4 files changed, 63 insertions(+)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index 0a42b87..4c787ce 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -36,6 +36,7 @@
 #define QEMU_VM_CONFIGURATION0x07
 #define QEMU_VM_COMMAND  0x08
 #define QEMU_VM_SECTION_FOOTER   0x7e
+#define QEMU_VM_ALMOST_COMPLETE  0x09
 
 struct MigrationParams {
 bool blk;
@@ -145,6 +146,11 @@ struct MigrationState
 int state;
 /* Old style params from 'migrate' command */
 MigrationParams params;
+/*
+ * Don't need 2 variables for recovery.
+ * Clean this up, use a single variable with different states.
+ */
+bool recovered_once;
 bool in_recovery;
 
 /* State related to return path */
@@ -360,6 +366,7 @@ int qemu_migrate_postcopy_incoming_recovery(QEMUFile 
**f,MigrationIncomingState*
 
 void migrate_incoming_ram_bitmap_init(void);
 void migrate_incoming_ram_bitmap_update(RAMBlock *rb, ram_addr_t addr);
+void *migrate_incoming_ram_req_pages(void *opaque);
 
 PostcopyState postcopy_state_get(void);
 /* Set the state and return the old state */
diff --git a/migration/migration.c b/migration/migration.c
index 99138dd..be24b69 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1042,6 +1042,7 @@ MigrationState *migrate_init(const MigrationParams 
*params)
 s->xfer_limit = 0;
 s->cleanup_bh = 0;
 s->to_dst_file = NULL;
+s->recovered_once = false;
 s->in_recovery = false;
 s->state = MIGRATION_STATUS_NONE;
 s->params = *params;
@@ -1918,6 +1919,7 @@ static void *migration_thread(void *opaque)
 if(ret == 0) {
 current_active_state = MIGRATION_STATUS_POSTCOPY_ACTIVE;
 runstate_set(RUN_STATE_FINISH_MIGRATE);
+s->recovered_once = true;
 qemu_file_clear_error(s->to_dst_file);
 continue;
 }
diff --git a/migration/ram.c b/migration/ram.c
index 4f16243..445b863 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2639,6 +2639,41 @@ void migrate_incoming_ram_bitmap_update(RAMBlock *rb, 
ram_addr_t addr)
 }
 }
 
+void *migrate_incoming_ram_req_pages(void* opaque)
+{
+MigrationIncomingState *mis = opaque;
+struct RAMBlock *rb;
+size_t hostpagesize = getpagesize();
+uint64_t addr;
+unsigned long base;
+unsigned long nr;
+unsigned long size;
+unsigned long next;
+unsigned long *not_received;
+
+not_received = atomic_rcu_read(_bitmap_rcu)->not_received;
+QLIST_FOREACH_RCU(rb, _list.blocks, next) {
+addr = 0;
+base = rb->offset >> TARGET_PAGE_BITS;
+size = base + (rb->used_length >> TARGET_PAGE_BITS);
+while (true) {
+nr = base + (addr >> TARGET_PAGE_BITS);
+next = find_next_bit(not_received, size, nr);
+addr = (next - base) << TARGET_PAGE_BITS;
+
+if (addr >= rb->used_length) {
+break;
+}
+else {
+migrate_send_rp_req_pages(mis, qemu_ram_get_idstr(rb),
+ addr, hostpagesize);
+addr++;
+}
+}
+}
+return NULL;
+}
+
 static SaveVMHandlers savevm_ram_handlers = {
 .save_live_setup = ram_save_setup,
 .save_live_iterate = ram_save_iterate,
diff --git a/migration/savevm.c b/migration/savevm.c
index 5fa39c1..103f0b8 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -986,6 +986,12 @@ void qemu_savevm_state_complete_postcopy(QEMUFile *f)
 {
 SaveStateEntry *se;
 int ret;
+MigrationState* ms = migrate_get_current();
+
+if (ms->recovered_once == true) {
+qemu_put_byte(f, QEMU_VM_ALMOST_COMPLETE);
+qemu_fflush(f);
+}
 
 QTAILQ_FOREACH(se, _state.handlers, entry) {
 if (!se->ops || !se->ops->save_live_complete_postcopy) {
@@ -1830,6 +1836,7 @@ static int qemu_loadvm_state_main(QEMUFile *f, 
MigrationIncomingState *mis)
 uint8_t section_type;
 int ret;
 PostcopyState ps;
+QemuThread req_pages_not_received;
 
 while ((section_type = qemu_get_byte(f)) != QEMU_VM_EOF) {
 
@@ -1851,6 +1858,18 @@ static int qemu_loadvm_state_main(QEMUFile *f, 
MigrationIncomingState *mis)
 return ret;
  }
 break;
+case QEMU_VM_ALMOST_COMPLETE:
+/*
+ * This case will only be used when migration recovers from a
+ * network failure during a postcopy migration.
+ * Now, send the requests for pages that were lost due to the
+ * network failure.
+ */
+

[Qemu-devel] [PATCH 1/2] Migration: New bitmap for postcopy migration failure

[Md Haris Iqbal]

Signed-off-by: Md Haris Iqbal 
---
 include/migration/migration.h |  3 +++
 migration/migration.c |  8 --
 migration/postcopy-ram.c  |  2 +-
 migration/ram.c   | 63 ++-
 4 files changed, 72 insertions(+), 4 deletions(-)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index 74d456e..0a42b87 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -358,6 +358,9 @@ int ram_save_queue_pages(MigrationState *ms, const char 
*rbname,
 int qemu_migrate_postcopy_outgoing_recovery(MigrationState *ms);
 int qemu_migrate_postcopy_incoming_recovery(QEMUFile 
**f,MigrationIncomingState* mis);
 
+void migrate_incoming_ram_bitmap_init(void);
+void migrate_incoming_ram_bitmap_update(RAMBlock *rb, ram_addr_t addr);
+
 PostcopyState postcopy_state_get(void);
 /* Set the state and return the old state */
 PostcopyState postcopy_state_set(PostcopyState new_state);
diff --git a/migration/migration.c b/migration/migration.c
index 4edd77c..99138dd 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -381,6 +381,10 @@ static void process_incoming_migration_co(void *opaque)
 postcopy_state_set(POSTCOPY_INCOMING_NONE);
 migrate_set_state(>state, MIGRATION_STATUS_NONE,
   MIGRATION_STATUS_ACTIVE);
+
+/* Initializing the bitmap for destination side */
+migrate_incoming_ram_bitmap_init();
+
 ret = qemu_loadvm_state(f);
 
 ps = postcopy_state_get();
diff --git a/migration/ram.c b/migration/ram.c
index 815bc0e..4f16243 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -250,6 +250,13 @@ static struct BitmapRcu {
  * of the postcopy phase
  */
 unsigned long *unsentmap;
+/*
+ * A new bitmap for postcopy network failure recovery.
+ * It keeps track of the pages recieved.
+ * In the end, it would be used to request pages that were
+ * lost due to network failure.
+ */
+unsigned long *not_received;
 } *migration_bitmap_rcu;
 
 struct CompressParam {
@@ -2340,6 +2347,7 @@ static int ram_load_postcopy(QEMUFile *f)
 void *page_buffer = NULL;
 void *place_source = NULL;
 uint8_t ch;
+RAMBlock* block = NULL;
 
 addr = qemu_get_be64(f);
 flags = addr & ~TARGET_PAGE_MASK;
@@ -2348,7 +2356,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)) {
-RAMBlock *block = ram_block_from_stream(f, flags);
+block = ram_block_from_stream(f, flags);
 
 host = host_from_ram_block_offset(block, addr);
 if (!host) {
@@ -2436,6 +2444,15 @@ static int ram_load_postcopy(QEMUFile *f)
 if (!ret) {
 ret = qemu_file_get_error(f);
 }
+if (block != NULL) {
+/*
+ * TODO
+ * We need to delay updating the bits until host page is
+ * recieved and the place is done, or tidy up the bitmap later
+ * accordingly (whether whole host page was recieved or not)
+ */
+migrate_incoming_ram_bitmap_update(block, addr);
+}
 }
 
 return ret;
@@ -2483,6 +2500,16 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
 RAMBlock *block = ram_block_from_stream(f, flags);
 
 host = host_from_ram_block_offset(block, addr);
+
+migrate_incoming_ram_bitmap_update(block, addr);
+/*
+ * TODO
+ * 1) Do we need a bitmap_update call later in the while loop also?
+ * 2) We need to delay updating the bits until host page is
+ * recieved and the place is done, or tidy up the bitmap later
+ * accordingly (whether whole host page was recieved or not)
+ */
+
 if (!host) {
 error_report("Illegal RAM offset " RAM_ADDR_FMT, addr);
 ret = -EINVAL;
@@ -2578,6 +2605,40 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
 return ret;
 }
 
+void migrate_incoming_ram_bitmap_init(void)
+{
+int64_t ram_bitmap_pages; /* Size of bitmap in pages, including gaps */
+
+/*
+ * A new bitmap for postcopy network failure recovery.
+ * It keeps track of the pages recieved.
+ * In the end, it would be used to request pages that were
+ * lost due to network failure.
+ */
+
+ram_bitmap_pages = last_ram_offset() >> TARGET_PAGE_BITS;
+migration_bitmap_rcu = g_new0(struct BitmapRcu, 1);
+migration_bitmap_rcu->not_received = bitmap_new(ram_bitmap_pages);
+bitmap_set(migration_bitmap_rcu->not_received, 0, ram_bitmap_pages);
+}
+
+void migrate_incoming_ram_bitmap_update(RAMBlock *rb, ram_addr_t addr)
+{
+unsigned long base = rb->offset >> TARGET_PAGE_BITS;
+unsigned long nr = base 

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Tian, Kevin]

> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, August 16, 2016 6:48 AM
> 
> On Mon, 15 Aug 2016 12:59:08 -0700
> Neo Jia  wrote:
> 
> > On Mon, Aug 15, 2016 at 09:38:52AM +, Tian, Kevin wrote:
> > > > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > > > Sent: Saturday, August 13, 2016 8:37 AM
> > > >
> > > >
> > > >
> > > > On 8/13/2016 2:46 AM, Alex Williamson wrote:
> > > > > On Sat, 13 Aug 2016 00:14:39 +0530
> > > > > Kirti Wankhede  wrote:
> > > > >
> > > > >> On 8/10/2016 12:30 AM, Alex Williamson wrote:
> > > > >>> On Thu, 4 Aug 2016 00:33:51 +0530
> > > > >>> Kirti Wankhede  wrote:
> > > > >>>
> > > > >>> This is used later by mdev_device_start() and mdev_device_stop() to 
> > > > >>> get
> > > > >>> the parent_device so it can call the start and stop ops callbacks
> > > > >>> respectively.  That seems to imply that all of instances for a given
> > > > >>> uuid come from the same parent_device.  Where is that enforced?  I'm
> > > > >>> still having a hard time buying into the uuid+instance plan when it
> > > > >>> seems like each mdev_device should have an actual unique uuid.
> > > > >>> Userspace tools can figure out which uuids to start for a given 
> > > > >>> user, I
> > > > >>> don't see much value in collecting them to instances within a uuid.
> > > > >>>
> > > > >>
> > > > >> Initially we started discussion with VM_UUID+instance suggestion, 
> > > > >> where
> > > > >> instance was introduced to support multiple devices in a VM.
> > > > >
> > > > > The instance number was never required in order to support multiple
> > > > > devices in a VM, IIRC this UUID+instance scheme was to appease NVIDIA
> > > > > management tools which wanted to re-use the VM UUID by creating vGPU
> > > > > devices with that same UUID and therefore associate udev events to a
> > > > > given VM.  Only then does an instance number become necessary since 
> > > > > the
> > > > > UUID needs to be static for a vGPUs within a VM.  This has always felt
> > > > > like a very dodgy solution when we should probably just be querying
> > > > > libvirt to give us a device to VM association.
> > >
> > > Agree with Alex here. We'd better not assume that UUID will be a VM_UUID
> > > for mdev in the basic design. It's bound to NVIDIA management stack too 
> > > tightly.
> > >
> > > I'm OK to give enough flexibility for various upper level management 
> > > stacks,
> > > e.g. instead of $UUID+INDEX style, would $UUID+STRING provide a better
> > > option where either UUID or STRING could be optional? Upper management
> > > stack can choose its own policy to identify a mdev:
> > >
> > > a) $UUID only, so each mdev is allocated with a unique UUID
> > > b) STRING only, which could be an index (0, 1, 2, ...), or any combination
> > > (vgpu0, vgpu1, etc.)
> > > c) $UUID+STRING, where UUID could be a VM UUID, and STRING could be
> > > a numeric index
> > >
> > > > >
> > > > >> 'mdev_create' creates device and 'mdev_start' is to commit resources 
> > > > >> of
> > > > >> all instances of similar devices assigned to VM.
> > > > >>
> > > > >> For example, to create 2 devices:
> > > > >> # echo "$UUID:0:params" > /sys/devices/../mdev_create
> > > > >> # echo "$UUID:1:params" > /sys/devices/../mdev_create
> > > > >>
> > > > >> "$UUID-0" and "$UUID-1" devices are created.
> > > > >>
> > > > >> Commit resources for above devices with single 'mdev_start':
> > > > >> # echo "$UUID" > /sys/class/mdev/mdev_start
> > > > >>
> > > > >> Considering $UUID to be a unique UUID of a device, we don't need
> > > > >> 'instance', so 'mdev_create' would look like:
> > > > >>
> > > > >> # echo "$UUID1:params" > /sys/devices/../mdev_create
> > > > >> # echo "$UUID2:params" > /sys/devices/../mdev_create
> > > > >>
> > > > >> where $UUID1 and $UUID2 would be mdev device's unique UUID and 
> > > > >> 'params'
> > > > >> would be vendor specific parameters.
> > > > >>
> > > > >> Device nodes would be created as "$UUID1" and "$UUID"
> > > > >>
> > > > >> Then 'mdev_start' would be:
> > > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_start
> > > > >>
> > > > >> Similarly 'mdev_stop' and 'mdev_destroy' would be:
> > > > >>
> > > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_stop
> > > > >
> > > > > I'm not sure a comma separated list makes sense here, for both
> > > > > simplicity in the kernel and more fine grained error reporting, we
> > > > > probably want to start/stop them individually.  Actually, why is it
> > > > > that we can't use the mediated device being opened and released to
> > > > > automatically signal to the backend vendor driver to commit and 
> > > > > release
> > > > > resources? I don't fully understand why userspace needs this 
> > > > > interface.
> > >
> > > There is a meaningful use of start/stop interface, as required in live
> > > migration support. Such interface allows vendor driver to quiescent
> > > mdev activity on source device 

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Neo Jia]

On Mon, Aug 15, 2016 at 04:47:41PM -0600, Alex Williamson wrote:
> On Mon, 15 Aug 2016 12:59:08 -0700
> Neo Jia  wrote:
> 
> > On Mon, Aug 15, 2016 at 09:38:52AM +, Tian, Kevin wrote:
> > > > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > > > Sent: Saturday, August 13, 2016 8:37 AM
> > > > 
> > > > 
> > > > 
> > > > On 8/13/2016 2:46 AM, Alex Williamson wrote:  
> > > > > On Sat, 13 Aug 2016 00:14:39 +0530
> > > > > Kirti Wankhede  wrote:
> > > > >  
> > > > >> On 8/10/2016 12:30 AM, Alex Williamson wrote:  
> > > > >>> On Thu, 4 Aug 2016 00:33:51 +0530
> > > > >>> Kirti Wankhede  wrote:
> > > > >>>
> > > > >>> This is used later by mdev_device_start() and mdev_device_stop() to 
> > > > >>> get
> > > > >>> the parent_device so it can call the start and stop ops callbacks
> > > > >>> respectively.  That seems to imply that all of instances for a given
> > > > >>> uuid come from the same parent_device.  Where is that enforced?  I'm
> > > > >>> still having a hard time buying into the uuid+instance plan when it
> > > > >>> seems like each mdev_device should have an actual unique uuid.
> > > > >>> Userspace tools can figure out which uuids to start for a given 
> > > > >>> user, I
> > > > >>> don't see much value in collecting them to instances within a uuid.
> > > > >>>  
> > > > >>
> > > > >> Initially we started discussion with VM_UUID+instance suggestion, 
> > > > >> where
> > > > >> instance was introduced to support multiple devices in a VM.  
> > > > >
> > > > > The instance number was never required in order to support multiple
> > > > > devices in a VM, IIRC this UUID+instance scheme was to appease NVIDIA
> > > > > management tools which wanted to re-use the VM UUID by creating vGPU
> > > > > devices with that same UUID and therefore associate udev events to a
> > > > > given VM.  Only then does an instance number become necessary since 
> > > > > the
> > > > > UUID needs to be static for a vGPUs within a VM.  This has always felt
> > > > > like a very dodgy solution when we should probably just be querying
> > > > > libvirt to give us a device to VM association.  
> > > 
> > > Agree with Alex here. We'd better not assume that UUID will be a VM_UUID
> > > for mdev in the basic design. It's bound to NVIDIA management stack too 
> > > tightly.
> > > 
> > > I'm OK to give enough flexibility for various upper level management 
> > > stacks,
> > > e.g. instead of $UUID+INDEX style, would $UUID+STRING provide a better
> > > option where either UUID or STRING could be optional? Upper management 
> > > stack can choose its own policy to identify a mdev:
> > > 
> > > a) $UUID only, so each mdev is allocated with a unique UUID
> > > b) STRING only, which could be an index (0, 1, 2, ...), or any 
> > > combination 
> > > (vgpu0, vgpu1, etc.)
> > > c) $UUID+STRING, where UUID could be a VM UUID, and STRING could be
> > > a numeric index
> > >   
> > > > >  
> > > > >> 'mdev_create' creates device and 'mdev_start' is to commit resources 
> > > > >> of
> > > > >> all instances of similar devices assigned to VM.
> > > > >>
> > > > >> For example, to create 2 devices:
> > > > >> # echo "$UUID:0:params" > /sys/devices/../mdev_create
> > > > >> # echo "$UUID:1:params" > /sys/devices/../mdev_create
> > > > >>
> > > > >> "$UUID-0" and "$UUID-1" devices are created.
> > > > >>
> > > > >> Commit resources for above devices with single 'mdev_start':
> > > > >> # echo "$UUID" > /sys/class/mdev/mdev_start
> > > > >>
> > > > >> Considering $UUID to be a unique UUID of a device, we don't need
> > > > >> 'instance', so 'mdev_create' would look like:
> > > > >>
> > > > >> # echo "$UUID1:params" > /sys/devices/../mdev_create
> > > > >> # echo "$UUID2:params" > /sys/devices/../mdev_create
> > > > >>
> > > > >> where $UUID1 and $UUID2 would be mdev device's unique UUID and 
> > > > >> 'params'
> > > > >> would be vendor specific parameters.
> > > > >>
> > > > >> Device nodes would be created as "$UUID1" and "$UUID"
> > > > >>
> > > > >> Then 'mdev_start' would be:
> > > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_start
> > > > >>
> > > > >> Similarly 'mdev_stop' and 'mdev_destroy' would be:
> > > > >>
> > > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_stop  
> > > > >
> > > > > I'm not sure a comma separated list makes sense here, for both
> > > > > simplicity in the kernel and more fine grained error reporting, we
> > > > > probably want to start/stop them individually.  Actually, why is it
> > > > > that we can't use the mediated device being opened and released to
> > > > > automatically signal to the backend vendor driver to commit and 
> > > > > release
> > > > > resources? I don't fully understand why userspace needs this 
> > > > > interface.  
> > > 
> > > There is a meaningful use of start/stop interface, as required in live
> > > migration support. Such interface allows vendor driver to quiescent 
> > > mdev activity on source device 

Re: [Qemu-devel] [PATCH COLO-Frame v18 00/34] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service (FT)

[Changlong Xie]

On 08/03/2016 08:25 PM, zhanghailiang wrote:

It is based on '[PATCH v24 00/12] Block replication for continuous checkpoints' 
series.
The complete codes can be found from the link:
https://github.com/coloft/qemu/commits/colo-v3.1-periodic-mode


404 NOT FOUND. Would you like to upload it again :)

Thanks
-Xie

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Neo Jia]

On Mon, Aug 15, 2016 at 04:52:39PM -0600, Alex Williamson wrote:
> On Mon, 15 Aug 2016 15:09:30 -0700
> Neo Jia  wrote:
> 
> > On Mon, Aug 15, 2016 at 09:59:26AM -0600, Alex Williamson wrote:
> > > On Mon, 15 Aug 2016 09:38:52 +
> > > "Tian, Kevin"  wrote:
> > >   
> > > > > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > > > > Sent: Saturday, August 13, 2016 8:37 AM
> > > > > 
> > > > > 
> > > > > 
> > > > > On 8/13/2016 2:46 AM, Alex Williamson wrote:
> > > > > > On Sat, 13 Aug 2016 00:14:39 +0530
> > > > > > Kirti Wankhede  wrote:
> > > > > >
> > > > > >> On 8/10/2016 12:30 AM, Alex Williamson wrote:
> > > > > >>> On Thu, 4 Aug 2016 00:33:51 +0530
> > > > > >>> Kirti Wankhede  wrote:
> > > > > >>>
> > > > > >>> This is used later by mdev_device_start() and mdev_device_stop() 
> > > > > >>> to get
> > > > > >>> the parent_device so it can call the start and stop ops callbacks
> > > > > >>> respectively.  That seems to imply that all of instances for a 
> > > > > >>> given
> > > > > >>> uuid come from the same parent_device.  Where is that enforced?  
> > > > > >>> I'm
> > > > > >>> still having a hard time buying into the uuid+instance plan when 
> > > > > >>> it
> > > > > >>> seems like each mdev_device should have an actual unique uuid.
> > > > > >>> Userspace tools can figure out which uuids to start for a given 
> > > > > >>> user, I
> > > > > >>> don't see much value in collecting them to instances within a 
> > > > > >>> uuid.
> > > > > >>>
> > > > > >>
> > > > > >> Initially we started discussion with VM_UUID+instance suggestion, 
> > > > > >> where
> > > > > >> instance was introduced to support multiple devices in a VM.
> > > > > >
> > > > > > The instance number was never required in order to support multiple
> > > > > > devices in a VM, IIRC this UUID+instance scheme was to appease 
> > > > > > NVIDIA
> > > > > > management tools which wanted to re-use the VM UUID by creating vGPU
> > > > > > devices with that same UUID and therefore associate udev events to a
> > > > > > given VM.  Only then does an instance number become necessary since 
> > > > > > the
> > > > > > UUID needs to be static for a vGPUs within a VM.  This has always 
> > > > > > felt
> > > > > > like a very dodgy solution when we should probably just be querying
> > > > > > libvirt to give us a device to VM association.
> > > > 
> > > > Agree with Alex here. We'd better not assume that UUID will be a VM_UUID
> > > > for mdev in the basic design. It's bound to NVIDIA management stack too 
> > > > tightly.
> > > > 
> > > > I'm OK to give enough flexibility for various upper level management 
> > > > stacks,
> > > > e.g. instead of $UUID+INDEX style, would $UUID+STRING provide a better
> > > > option where either UUID or STRING could be optional? Upper management 
> > > > stack can choose its own policy to identify a mdev:
> > > > 
> > > > a) $UUID only, so each mdev is allocated with a unique UUID
> > > > b) STRING only, which could be an index (0, 1, 2, ...), or any 
> > > > combination 
> > > > (vgpu0, vgpu1, etc.)
> > > > c) $UUID+STRING, where UUID could be a VM UUID, and STRING could be
> > > > a numeric index
> > > >   
> > > > > >
> > > > > >> 'mdev_create' creates device and 'mdev_start' is to commit 
> > > > > >> resources of
> > > > > >> all instances of similar devices assigned to VM.
> > > > > >>
> > > > > >> For example, to create 2 devices:
> > > > > >> # echo "$UUID:0:params" > /sys/devices/../mdev_create
> > > > > >> # echo "$UUID:1:params" > /sys/devices/../mdev_create
> > > > > >>
> > > > > >> "$UUID-0" and "$UUID-1" devices are created.
> > > > > >>
> > > > > >> Commit resources for above devices with single 'mdev_start':
> > > > > >> # echo "$UUID" > /sys/class/mdev/mdev_start
> > > > > >>
> > > > > >> Considering $UUID to be a unique UUID of a device, we don't need
> > > > > >> 'instance', so 'mdev_create' would look like:
> > > > > >>
> > > > > >> # echo "$UUID1:params" > /sys/devices/../mdev_create
> > > > > >> # echo "$UUID2:params" > /sys/devices/../mdev_create
> > > > > >>
> > > > > >> where $UUID1 and $UUID2 would be mdev device's unique UUID and 
> > > > > >> 'params'
> > > > > >> would be vendor specific parameters.
> > > > > >>
> > > > > >> Device nodes would be created as "$UUID1" and "$UUID"
> > > > > >>
> > > > > >> Then 'mdev_start' would be:
> > > > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_start
> > > > > >>
> > > > > >> Similarly 'mdev_stop' and 'mdev_destroy' would be:
> > > > > >>
> > > > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_stop
> > > > > >
> > > > > > I'm not sure a comma separated list makes sense here, for both
> > > > > > simplicity in the kernel and more fine grained error reporting, we
> > > > > > probably want to start/stop them individually.  Actually, why is it
> > > > > > that we can't use the mediated device being opened and 

Re: [Qemu-devel] [PATCH v3] balloon: Fix failure of updating guest memory status

[Michael S. Tsirkin]

On Fri, Aug 05, 2016 at 01:36:32PM +0200, Ladi Prosek wrote:
> The stats_vq_elem field keeps track of the state of the balloon stats
> virtqueue protocol but it wasn't preserved across migrations, resulting
> in losing guest memory status updates on the receiving VM.
> 
> This commit adds a new VM state change handler which resets stats_vq_elem
> to NULL when the VM is stopped, eliminating the need for the field to be
> migrated. When the VM starts running again, the field is reinitialized by
> re-popping the element from the virtqueue.
> 
> Signed-off-by: Ladi Prosek 
> Suggested-by: Michael S. Tsirkin 

I think that for the 2.7 machine type, we should
also migrate the guest-stats-polling-interval property.

Otherwise the value that was set on source
is not forwarded to the destination
properly.

And at that point, one wanders whether we should
check the interval is set before receive calling
stats.


> ---
>  hw/virtio/virtio-balloon.c | 23 +++
>  include/hw/virtio/virtio-balloon.h |  1 +
>  2 files changed, 24 insertions(+)
> 
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index 5af429a..65457e9 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -423,6 +423,26 @@ static int virtio_balloon_load_device(VirtIODevice 
> *vdev, QEMUFile *f,
>  return 0;
>  }
>  
> +static void virtio_balloon_vmstate_cb(void *opaque, int running,
> +  RunState state)
> +{
> +VirtIOBalloon *s = opaque;
> +
> +if (!running) {
> +/* put the stats element back if the VM is not running */
> +if (s->stats_vq_elem != NULL) {
> +virtqueue_discard(s->svq, s->stats_vq_elem, s->stats_vq_offset);
> +g_free(s->stats_vq_elem);
> +s->stats_vq_elem = NULL;
> +}
> +
> +} else {
> +/* poll stats queue for the element we may have discarded
> + * when the VM was stopped */
> +virtio_balloon_receive_stats(VIRTIO_DEVICE(s), s->svq);
> +}
> +}
> +
>  static void virtio_balloon_device_realize(DeviceState *dev, Error **errp)
>  {
>  VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> @@ -446,6 +466,8 @@ static void virtio_balloon_device_realize(DeviceState 
> *dev, Error **errp)
>  s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
>  
>  reset_stats(s);
> +
> +s->change = qemu_add_vm_change_state_handler(virtio_balloon_vmstate_cb, 
> s);
>  }
>  
>  static void virtio_balloon_device_unrealize(DeviceState *dev, Error **errp)
> @@ -453,6 +475,7 @@ static void virtio_balloon_device_unrealize(DeviceState 
> *dev, Error **errp)
>  VirtIODevice *vdev = VIRTIO_DEVICE(dev);
>  VirtIOBalloon *s = VIRTIO_BALLOON(dev);
>  
> +qemu_del_vm_change_state_handler(s->change);
>  balloon_stats_destroy_timer(s);
>  qemu_remove_balloon_handler(s);
>  virtio_cleanup(vdev);
> diff --git a/include/hw/virtio/virtio-balloon.h 
> b/include/hw/virtio/virtio-balloon.h
> index 1ea13bd..d72ff7f 100644
> --- a/include/hw/virtio/virtio-balloon.h
> +++ b/include/hw/virtio/virtio-balloon.h
> @@ -43,6 +43,7 @@ typedef struct VirtIOBalloon {
>  int64_t stats_last_update;
>  int64_t stats_poll_interval;
>  uint32_t host_features;
> +VMChangeStateEntry *change;
>  } VirtIOBalloon;
>  
>  #endif
> -- 
> 2.5.5

[Qemu-devel] [PATCH] virtio-balloon: stats vq migration spec compliance

[Michael S. Tsirkin]

virtio spec says that devices must not touch VQs
before DRIVER_OK is set.

Additionally, balloon must not touch stats VQ
unless the stats feature bit has been negotiated.

Cc: Ladi Prosek 
Signed-off-by: Michael S. Tsirkin 
---
 hw/virtio/virtio-balloon.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 65457e9..7189260 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -427,6 +427,7 @@ static void virtio_balloon_vmstate_cb(void *opaque, int 
running,
   RunState state)
 {
 VirtIOBalloon *s = opaque;
+VirtIODevice *vdev = VIRTIO_DEVICE(s);
 
 if (!running) {
 /* put the stats element back if the VM is not running */
@@ -436,7 +437,8 @@ static void virtio_balloon_vmstate_cb(void *opaque, int 
running,
 s->stats_vq_elem = NULL;
 }
 
-} else {
+} else if (balloon_stats_supported(s) &&
+   (vdev->status & VIRTIO_CONFIG_S_DRIVER_OK)) {
 /* poll stats queue for the element we may have discarded
  * when the VM was stopped */
 virtio_balloon_receive_stats(VIRTIO_DEVICE(s), s->svq);
-- 
MST

Re: [Qemu-devel] [PATCH V1 1/1] arm64: Add an option to turn on/off host-backed vPMU support

[Wei Huang]

On 8/15/16 11:13, Peter Maydell wrote:
> On 13 August 2016 at 06:52, Wei Huang  wrote:
>> This patch adds a pmu=[on/off] option to enable/disable host vPMU
>> support in guest VM. There are several reasons to justify this option.
>> First, host-backed vPMU can be problematic for cross-migration between
>> different SoC as perf counters are architecture-dependent. It is more
>> flexible to have an option to turn it on/off. Secondly this option
>> matches the "pmu" option as supported in libvirt tool.
>>
>> Note that, like "has_el3", the "pmu" option is only made available on
>> CPUs that support host-backed vPMU. They include:
>> * cortex-a53 + kvm
>> * cortex-a57 + kvm
>> * host + kvm
>> This option is removed in other configs where it doesn't make sense
>> (e.g. cortex-a57 + TCG); and the default pmu support is off. This patch
>> has been tested under both DT/ACPI modes.
>>
>> Signed-off-by: Wei Huang 
>> ---
>>  hw/arm/virt-acpi-build.c |  2 +-
>>  hw/arm/virt.c|  2 +-
>>  target-arm/cpu.c | 13 +
>>  target-arm/cpu.h |  3 ++-
>>  target-arm/cpu64.c   |  6 ++
>>  target-arm/kvm64.c   | 10 +-
>>  6 files changed, 28 insertions(+), 8 deletions(-)
>>
>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
>> index 28fc59c..22fb9d9 100644
>> --- a/hw/arm/virt-acpi-build.c
>> +++ b/hw/arm/virt-acpi-build.c
>> @@ -540,7 +540,7 @@ build_madt(GArray *table_data, BIOSLinker *linker, 
>> VirtGuestInfo *guest_info)
>>  gicc->uid = i;
>>  gicc->flags = cpu_to_le32(ACPI_GICC_ENABLED);
>>
>> -if (armcpu->has_pmu) {
>> +if (armcpu->has_host_pmu) {
>>  gicc->performance_interrupt = cpu_to_le32(PPI(VIRTUAL_PMU_IRQ));
>>  }
>>  }
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index a193b5a..4975f38 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -477,7 +477,7 @@ static void fdt_add_pmu_nodes(const VirtBoardInfo *vbi, 
>> int gictype)
>>
>>  CPU_FOREACH(cpu) {
>>  armcpu = ARM_CPU(cpu);
>> -if (!armcpu->has_pmu ||
>> +if (!armcpu->has_host_pmu ||
>>  !kvm_arm_pmu_create(cpu, PPI(VIRTUAL_PMU_IRQ))) {
>>  return;
>>  }
>> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
>> index ce8b8f4..a527128 100644
>> --- a/target-arm/cpu.c
>> +++ b/target-arm/cpu.c
>> @@ -509,6 +509,10 @@ static Property arm_cpu_rvbar_property =
>>  static Property arm_cpu_has_el3_property =
>>  DEFINE_PROP_BOOL("has_el3", ARMCPU, has_el3, true);
>>
>> +/* use property name "pmu" to match with other archs and libvirt */
>> +static Property arm_cpu_has_host_pmu_property =
>> +DEFINE_PROP_BOOL("pmu", ARMCPU, has_host_pmu, false);
>> +
>>  static Property arm_cpu_has_mpu_property =
>>  DEFINE_PROP_BOOL("has-mpu", ARMCPU, has_mpu, true);
>>
>> @@ -552,6 +556,11 @@ static void arm_cpu_post_init(Object *obj)
>>  #endif
>>  }
>>
>> +if (arm_feature(>env, ARM_FEATURE_HOST_PMU)) {
>> +qdev_property_add_static(DEVICE(obj), 
>> _cpu_has_host_pmu_property,
>> + _abort);
>> +}
>> +
>>  if (arm_feature(>env, ARM_FEATURE_MPU)) {
>>  qdev_property_add_static(DEVICE(obj), _cpu_has_mpu_property,
>>   _abort);
>> @@ -648,6 +657,10 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
>> **errp)
>>  cpu->id_aa64pfr0 &= ~0xf000;
>>  }
>>
>> +if (!cpu->has_host_pmu) {
>> +unset_feature(env, ARM_FEATURE_HOST_PMU);
>> +}
>> +
>>  if (!arm_feature(env, ARM_FEATURE_EL2)) {
>>  /* Disable the hypervisor feature bits in the processor feature
>>   * registers if we don't have EL2. These are id_pfr1[15:12] and
>> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
>> index 76d824d..f3f6d3f 100644
>> --- a/target-arm/cpu.h
>> +++ b/target-arm/cpu.h
>> @@ -580,7 +580,7 @@ struct ARMCPU {
>>  /* CPU has security extension */
>>  bool has_el3;
>>  /* CPU has PMU (Performance Monitor Unit) */
>> -bool has_pmu;
>> +bool has_host_pmu;
> 
> Can you explain why you renamed this? "has_pmu" matches
> the comment: it indicates that the emulated CPU has a PMU.
> has_host_pmu would be something different (and would only

The existing "has_pmu" was added and only enabled under KVM. So its
existing meaning is a bit misleading. It doesn't address the case of TCG.


> apply to KVM). It also looks weird in the code in the board
> model: we should be saying "if the guest CPU has a PMU, wire
> up its interrupt", not "if the host CPU has a PMU, wire
> up a guest CPU interrupt".

I can change it back to "has_pmu" as suggested by you and Drew; but we
need to be careful of using it, especially under TCG mode. For instance,
with "-M virt,accel=tcg -cpu host,pmu=off", we expect PMU is turned off.
But TCG still emulates some PMU counters (e.g. pmccntr).

> 
>>
>>  /* CPU 

Re: [Qemu-devel] [PATCH for-2.7 0/4] virtio-balloon: fix stats vq migration

[Michael S. Tsirkin]

On Mon, Aug 15, 2016 at 09:51:21PM +0200, Gaudenz Steinlin wrote:
> Stefan Hajnoczi  writes:
> 
> > Gaudenz Steinlin  reported that virtqueue_pop() 
> > terminates
> > QEMU because the virtqueue size is exceeded following the CVE-2016-5403 
> > fix.  I
> > have been unable to reproduce this or understand the root cause by code
> > inspection.  Along the way I did discover a few bugs in virtio-balloon and
> > virtio code.
> >
> > Please see the individual patches for details.
> >
> > Gaudenz: If you can reproduce the bug you reported, please try again with 
> > these
> > patches applied.
> 
> As mentioned in the original thread I only tested on QEMU 2.0.0 so far.
> I tried to apply your patches to this version, but did not succeed. I
> could not apply the first patch in the series because the code changed
> too much and with only the others applied QEMU failed to compile. I gave
> up at that point.
> 
> Does it make sense at all to test these patches on 2.0.0? Ubuntu
> reverted the problematic fix in their latest package update for trusty,
> so my immediate problem is "solved". Is there a chance to get a fix for
> CVE-2016-5403 that works on QEMU 2.0.0 without breaking migrations?
> 
> Best regards and thanks to all for the effort so far,
> Gaudenz

You will have to debug the failure I'm afraid.
Most likely inuse is incremented in pop but not
decremented.

Maybe you need

commit 0cf33fb6b49a19de32859e2cdc6021334f448fb3
Author: Jason Wang 
Date:   Fri Sep 25 13:21:30 2015 +0800

virtio-net: correctly drop truncated packets


It's hard to say.

-- 
MST

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Alex Williamson]

On Mon, 15 Aug 2016 15:09:30 -0700
Neo Jia  wrote:

> On Mon, Aug 15, 2016 at 09:59:26AM -0600, Alex Williamson wrote:
> > On Mon, 15 Aug 2016 09:38:52 +
> > "Tian, Kevin"  wrote:
> >   
> > > > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > > > Sent: Saturday, August 13, 2016 8:37 AM
> > > > 
> > > > 
> > > > 
> > > > On 8/13/2016 2:46 AM, Alex Williamson wrote:
> > > > > On Sat, 13 Aug 2016 00:14:39 +0530
> > > > > Kirti Wankhede  wrote:
> > > > >
> > > > >> On 8/10/2016 12:30 AM, Alex Williamson wrote:
> > > > >>> On Thu, 4 Aug 2016 00:33:51 +0530
> > > > >>> Kirti Wankhede  wrote:
> > > > >>>
> > > > >>> This is used later by mdev_device_start() and mdev_device_stop() to 
> > > > >>> get
> > > > >>> the parent_device so it can call the start and stop ops callbacks
> > > > >>> respectively.  That seems to imply that all of instances for a given
> > > > >>> uuid come from the same parent_device.  Where is that enforced?  I'm
> > > > >>> still having a hard time buying into the uuid+instance plan when it
> > > > >>> seems like each mdev_device should have an actual unique uuid.
> > > > >>> Userspace tools can figure out which uuids to start for a given 
> > > > >>> user, I
> > > > >>> don't see much value in collecting them to instances within a uuid.
> > > > >>>
> > > > >>
> > > > >> Initially we started discussion with VM_UUID+instance suggestion, 
> > > > >> where
> > > > >> instance was introduced to support multiple devices in a VM.
> > > > >
> > > > > The instance number was never required in order to support multiple
> > > > > devices in a VM, IIRC this UUID+instance scheme was to appease NVIDIA
> > > > > management tools which wanted to re-use the VM UUID by creating vGPU
> > > > > devices with that same UUID and therefore associate udev events to a
> > > > > given VM.  Only then does an instance number become necessary since 
> > > > > the
> > > > > UUID needs to be static for a vGPUs within a VM.  This has always felt
> > > > > like a very dodgy solution when we should probably just be querying
> > > > > libvirt to give us a device to VM association.
> > > 
> > > Agree with Alex here. We'd better not assume that UUID will be a VM_UUID
> > > for mdev in the basic design. It's bound to NVIDIA management stack too 
> > > tightly.
> > > 
> > > I'm OK to give enough flexibility for various upper level management 
> > > stacks,
> > > e.g. instead of $UUID+INDEX style, would $UUID+STRING provide a better
> > > option where either UUID or STRING could be optional? Upper management 
> > > stack can choose its own policy to identify a mdev:
> > > 
> > > a) $UUID only, so each mdev is allocated with a unique UUID
> > > b) STRING only, which could be an index (0, 1, 2, ...), or any 
> > > combination 
> > > (vgpu0, vgpu1, etc.)
> > > c) $UUID+STRING, where UUID could be a VM UUID, and STRING could be
> > > a numeric index
> > >   
> > > > >
> > > > >> 'mdev_create' creates device and 'mdev_start' is to commit resources 
> > > > >> of
> > > > >> all instances of similar devices assigned to VM.
> > > > >>
> > > > >> For example, to create 2 devices:
> > > > >> # echo "$UUID:0:params" > /sys/devices/../mdev_create
> > > > >> # echo "$UUID:1:params" > /sys/devices/../mdev_create
> > > > >>
> > > > >> "$UUID-0" and "$UUID-1" devices are created.
> > > > >>
> > > > >> Commit resources for above devices with single 'mdev_start':
> > > > >> # echo "$UUID" > /sys/class/mdev/mdev_start
> > > > >>
> > > > >> Considering $UUID to be a unique UUID of a device, we don't need
> > > > >> 'instance', so 'mdev_create' would look like:
> > > > >>
> > > > >> # echo "$UUID1:params" > /sys/devices/../mdev_create
> > > > >> # echo "$UUID2:params" > /sys/devices/../mdev_create
> > > > >>
> > > > >> where $UUID1 and $UUID2 would be mdev device's unique UUID and 
> > > > >> 'params'
> > > > >> would be vendor specific parameters.
> > > > >>
> > > > >> Device nodes would be created as "$UUID1" and "$UUID"
> > > > >>
> > > > >> Then 'mdev_start' would be:
> > > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_start
> > > > >>
> > > > >> Similarly 'mdev_stop' and 'mdev_destroy' would be:
> > > > >>
> > > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_stop
> > > > >
> > > > > I'm not sure a comma separated list makes sense here, for both
> > > > > simplicity in the kernel and more fine grained error reporting, we
> > > > > probably want to start/stop them individually.  Actually, why is it
> > > > > that we can't use the mediated device being opened and released to
> > > > > automatically signal to the backend vendor driver to commit and 
> > > > > release
> > > > > resources? I don't fully understand why userspace needs this 
> > > > > interface.
> > > 
> > > There is a meaningful use of start/stop interface, as required in live
> > > migration support. Such interface allows vendor driver to 

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Alex Williamson]

On Mon, 15 Aug 2016 12:59:08 -0700
Neo Jia  wrote:

> On Mon, Aug 15, 2016 at 09:38:52AM +, Tian, Kevin wrote:
> > > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > > Sent: Saturday, August 13, 2016 8:37 AM
> > > 
> > > 
> > > 
> > > On 8/13/2016 2:46 AM, Alex Williamson wrote:  
> > > > On Sat, 13 Aug 2016 00:14:39 +0530
> > > > Kirti Wankhede  wrote:
> > > >  
> > > >> On 8/10/2016 12:30 AM, Alex Williamson wrote:  
> > > >>> On Thu, 4 Aug 2016 00:33:51 +0530
> > > >>> Kirti Wankhede  wrote:
> > > >>>
> > > >>> This is used later by mdev_device_start() and mdev_device_stop() to 
> > > >>> get
> > > >>> the parent_device so it can call the start and stop ops callbacks
> > > >>> respectively.  That seems to imply that all of instances for a given
> > > >>> uuid come from the same parent_device.  Where is that enforced?  I'm
> > > >>> still having a hard time buying into the uuid+instance plan when it
> > > >>> seems like each mdev_device should have an actual unique uuid.
> > > >>> Userspace tools can figure out which uuids to start for a given user, 
> > > >>> I
> > > >>> don't see much value in collecting them to instances within a uuid.
> > > >>>  
> > > >>
> > > >> Initially we started discussion with VM_UUID+instance suggestion, where
> > > >> instance was introduced to support multiple devices in a VM.  
> > > >
> > > > The instance number was never required in order to support multiple
> > > > devices in a VM, IIRC this UUID+instance scheme was to appease NVIDIA
> > > > management tools which wanted to re-use the VM UUID by creating vGPU
> > > > devices with that same UUID and therefore associate udev events to a
> > > > given VM.  Only then does an instance number become necessary since the
> > > > UUID needs to be static for a vGPUs within a VM.  This has always felt
> > > > like a very dodgy solution when we should probably just be querying
> > > > libvirt to give us a device to VM association.  
> > 
> > Agree with Alex here. We'd better not assume that UUID will be a VM_UUID
> > for mdev in the basic design. It's bound to NVIDIA management stack too 
> > tightly.
> > 
> > I'm OK to give enough flexibility for various upper level management stacks,
> > e.g. instead of $UUID+INDEX style, would $UUID+STRING provide a better
> > option where either UUID or STRING could be optional? Upper management 
> > stack can choose its own policy to identify a mdev:
> > 
> > a) $UUID only, so each mdev is allocated with a unique UUID
> > b) STRING only, which could be an index (0, 1, 2, ...), or any combination 
> > (vgpu0, vgpu1, etc.)
> > c) $UUID+STRING, where UUID could be a VM UUID, and STRING could be
> > a numeric index
> >   
> > > >  
> > > >> 'mdev_create' creates device and 'mdev_start' is to commit resources of
> > > >> all instances of similar devices assigned to VM.
> > > >>
> > > >> For example, to create 2 devices:
> > > >> # echo "$UUID:0:params" > /sys/devices/../mdev_create
> > > >> # echo "$UUID:1:params" > /sys/devices/../mdev_create
> > > >>
> > > >> "$UUID-0" and "$UUID-1" devices are created.
> > > >>
> > > >> Commit resources for above devices with single 'mdev_start':
> > > >> # echo "$UUID" > /sys/class/mdev/mdev_start
> > > >>
> > > >> Considering $UUID to be a unique UUID of a device, we don't need
> > > >> 'instance', so 'mdev_create' would look like:
> > > >>
> > > >> # echo "$UUID1:params" > /sys/devices/../mdev_create
> > > >> # echo "$UUID2:params" > /sys/devices/../mdev_create
> > > >>
> > > >> where $UUID1 and $UUID2 would be mdev device's unique UUID and 'params'
> > > >> would be vendor specific parameters.
> > > >>
> > > >> Device nodes would be created as "$UUID1" and "$UUID"
> > > >>
> > > >> Then 'mdev_start' would be:
> > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_start
> > > >>
> > > >> Similarly 'mdev_stop' and 'mdev_destroy' would be:
> > > >>
> > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_stop  
> > > >
> > > > I'm not sure a comma separated list makes sense here, for both
> > > > simplicity in the kernel and more fine grained error reporting, we
> > > > probably want to start/stop them individually.  Actually, why is it
> > > > that we can't use the mediated device being opened and released to
> > > > automatically signal to the backend vendor driver to commit and release
> > > > resources? I don't fully understand why userspace needs this interface. 
> > > >  
> > 
> > There is a meaningful use of start/stop interface, as required in live
> > migration support. Such interface allows vendor driver to quiescent 
> > mdev activity on source device before mdev hardware state is snapshot,
> > and then resume mdev activity on dest device after its state is recovered.
> > Intel has implemented experimental live migration support in KVMGT (soon
> > to release), based on above two interfaces (plus another two to get/set
> > mdev state).
> >   
> > > >  
> > > 
> > > For NVIDIA vGPU 

[Qemu-devel] [PATCH v4] fpu: add mechanism to check for invalid long double formats

[Andrew Dutcher]

All operations that take a floatx80 as an operand need to have their
inputs checked for malformed encodings. In all of these cases, use the
function floatx80_invalid_encoding to perform the check. If an invalid
operand is found, raise an invalid operation exception, and then return
either NaN (for fp-typed results) or the integer indefinite value (the
minimum representable signed integer value, for int-typed results).

Signed-off-by: Andrew Dutcher 
---

Version 4: Remove comments, since apparently it's still 1998. If anyone wants
to know what the value is for, they can check git blame.

 fpu/softfloat.c | 60 +
 include/fpu/softfloat.h | 15 +
 2 files changed, 75 insertions(+)

diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 9b1eccf..5ff5df5 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloat.c
@@ -4814,6 +4814,10 @@ int32_t floatx80_to_int32(floatx80 a, float_status 
*status)
 int32_t aExp, shiftCount;
 uint64_t aSig;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return 1 << 31;
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -4842,6 +4846,10 @@ int32_t floatx80_to_int32_round_to_zero(floatx80 a, 
float_status *status)
 uint64_t aSig, savedASig;
 int32_t z;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return 1 << 31;
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -4888,6 +4896,10 @@ int64_t floatx80_to_int64(floatx80 a, float_status 
*status)
 int32_t aExp, shiftCount;
 uint64_t aSig, aSigExtra;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return 1 << 63;
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -4929,6 +4941,10 @@ int64_t floatx80_to_int64_round_to_zero(floatx80 a, 
float_status *status)
 uint64_t aSig;
 int64_t z;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return 1 << 63;
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -4971,6 +4987,10 @@ float32 floatx80_to_float32(floatx80 a, float_status 
*status)
 int32_t aExp;
 uint64_t aSig;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return float32_default_nan(status);
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -4999,6 +5019,10 @@ float64 floatx80_to_float64(floatx80 a, float_status 
*status)
 int32_t aExp;
 uint64_t aSig, zSig;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return float64_default_nan(status);
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -5027,6 +5051,10 @@ float128 floatx80_to_float128(floatx80 a, float_status 
*status)
 int aExp;
 uint64_t aSig, zSig0, zSig1;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return float128_default_nan(status);
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -5052,6 +5080,10 @@ floatx80 floatx80_round_to_int(floatx80 a, float_status 
*status)
 uint64_t lastBitMask, roundBitsMask;
 floatx80 z;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return floatx80_default_nan(status);
+}
 aExp = extractFloatx80Exp( a );
 if ( 0x403E <= aExp ) {
 if ( ( aExp == 0x7FFF ) && (uint64_t) ( extractFloatx80Frac( a )<<1 ) 
) {
@@ -5279,6 +5311,10 @@ floatx80 floatx80_add(floatx80 a, floatx80 b, 
float_status *status)
 {
 flag aSign, bSign;
 
+if (floatx80_invalid_encoding(a) || floatx80_invalid_encoding(b)) {
+float_raise(float_flag_invalid, status);
+return floatx80_default_nan(status);
+}
 aSign = extractFloatx80Sign( a );
 bSign = extractFloatx80Sign( b );
 if ( aSign == bSign ) {
@@ -5300,6 +5336,10 @@ floatx80 floatx80_sub(floatx80 a, floatx80 b, 
float_status *status)
 {
 flag aSign, bSign;
 
+if (floatx80_invalid_encoding(a) || floatx80_invalid_encoding(b)) {
+float_raise(float_flag_invalid, status);
+return floatx80_default_nan(status);
+}
 aSign = extractFloatx80Sign( a );
 bSign = extractFloatx80Sign( b );
 if ( aSign == bSign ) {
@@ -5323,6 +5363,10 @@ floatx80 floatx80_mul(floatx80 a, floatx80 b, 
float_status *status)
 int32_t aExp, bExp, zExp;
 uint64_t aSig, bSig, zSig0, 

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Neo Jia]

On Mon, Aug 15, 2016 at 09:59:26AM -0600, Alex Williamson wrote:
> On Mon, 15 Aug 2016 09:38:52 +
> "Tian, Kevin"  wrote:
> 
> > > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > > Sent: Saturday, August 13, 2016 8:37 AM
> > > 
> > > 
> > > 
> > > On 8/13/2016 2:46 AM, Alex Williamson wrote:  
> > > > On Sat, 13 Aug 2016 00:14:39 +0530
> > > > Kirti Wankhede  wrote:
> > > >  
> > > >> On 8/10/2016 12:30 AM, Alex Williamson wrote:  
> > > >>> On Thu, 4 Aug 2016 00:33:51 +0530
> > > >>> Kirti Wankhede  wrote:
> > > >>>
> > > >>> This is used later by mdev_device_start() and mdev_device_stop() to 
> > > >>> get
> > > >>> the parent_device so it can call the start and stop ops callbacks
> > > >>> respectively.  That seems to imply that all of instances for a given
> > > >>> uuid come from the same parent_device.  Where is that enforced?  I'm
> > > >>> still having a hard time buying into the uuid+instance plan when it
> > > >>> seems like each mdev_device should have an actual unique uuid.
> > > >>> Userspace tools can figure out which uuids to start for a given user, 
> > > >>> I
> > > >>> don't see much value in collecting them to instances within a uuid.
> > > >>>  
> > > >>
> > > >> Initially we started discussion with VM_UUID+instance suggestion, where
> > > >> instance was introduced to support multiple devices in a VM.  
> > > >
> > > > The instance number was never required in order to support multiple
> > > > devices in a VM, IIRC this UUID+instance scheme was to appease NVIDIA
> > > > management tools which wanted to re-use the VM UUID by creating vGPU
> > > > devices with that same UUID and therefore associate udev events to a
> > > > given VM.  Only then does an instance number become necessary since the
> > > > UUID needs to be static for a vGPUs within a VM.  This has always felt
> > > > like a very dodgy solution when we should probably just be querying
> > > > libvirt to give us a device to VM association.  
> > 
> > Agree with Alex here. We'd better not assume that UUID will be a VM_UUID
> > for mdev in the basic design. It's bound to NVIDIA management stack too 
> > tightly.
> > 
> > I'm OK to give enough flexibility for various upper level management stacks,
> > e.g. instead of $UUID+INDEX style, would $UUID+STRING provide a better
> > option where either UUID or STRING could be optional? Upper management 
> > stack can choose its own policy to identify a mdev:
> > 
> > a) $UUID only, so each mdev is allocated with a unique UUID
> > b) STRING only, which could be an index (0, 1, 2, ...), or any combination 
> > (vgpu0, vgpu1, etc.)
> > c) $UUID+STRING, where UUID could be a VM UUID, and STRING could be
> > a numeric index
> > 
> > > >  
> > > >> 'mdev_create' creates device and 'mdev_start' is to commit resources of
> > > >> all instances of similar devices assigned to VM.
> > > >>
> > > >> For example, to create 2 devices:
> > > >> # echo "$UUID:0:params" > /sys/devices/../mdev_create
> > > >> # echo "$UUID:1:params" > /sys/devices/../mdev_create
> > > >>
> > > >> "$UUID-0" and "$UUID-1" devices are created.
> > > >>
> > > >> Commit resources for above devices with single 'mdev_start':
> > > >> # echo "$UUID" > /sys/class/mdev/mdev_start
> > > >>
> > > >> Considering $UUID to be a unique UUID of a device, we don't need
> > > >> 'instance', so 'mdev_create' would look like:
> > > >>
> > > >> # echo "$UUID1:params" > /sys/devices/../mdev_create
> > > >> # echo "$UUID2:params" > /sys/devices/../mdev_create
> > > >>
> > > >> where $UUID1 and $UUID2 would be mdev device's unique UUID and 'params'
> > > >> would be vendor specific parameters.
> > > >>
> > > >> Device nodes would be created as "$UUID1" and "$UUID"
> > > >>
> > > >> Then 'mdev_start' would be:
> > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_start
> > > >>
> > > >> Similarly 'mdev_stop' and 'mdev_destroy' would be:
> > > >>
> > > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_stop  
> > > >
> > > > I'm not sure a comma separated list makes sense here, for both
> > > > simplicity in the kernel and more fine grained error reporting, we
> > > > probably want to start/stop them individually.  Actually, why is it
> > > > that we can't use the mediated device being opened and released to
> > > > automatically signal to the backend vendor driver to commit and release
> > > > resources? I don't fully understand why userspace needs this interface. 
> > > >  
> > 
> > There is a meaningful use of start/stop interface, as required in live
> > migration support. Such interface allows vendor driver to quiescent 
> > mdev activity on source device before mdev hardware state is snapshot,
> > and then resume mdev activity on dest device after its state is recovered.
> > Intel has implemented experimental live migration support in KVMGT (soon
> > to release), based on above two interfaces (plus another two to get/set
> > mdev state).
> 
> Ok, that's actually an 

Re: [Qemu-devel] [PATCH v3] fpu: add mechanism to check for invalid long double formats

[no-reply]

Hi,

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

Message-id: 1471298004-5959-1-git-send-email-and...@andrewdutcher.com
Subject: [Qemu-devel] [PATCH v3] fpu: add mechanism to check for invalid long 
double formats
Type: series

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

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

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/1471298004-5959-1-git-send-email-and...@andrewdutcher.com -> 
patchew/1471298004-5959-1-git-send-email-and...@andrewdutcher.com
Switched to a new branch 'test'
8a7e23e fpu: add mechanism to check for invalid long double formats

=== OUTPUT BEGIN ===
Checking PATCH 1/1: fpu: add mechanism to check for invalid long double 
formats...
ERROR: do not use C99 // comments
#26: FILE: fpu/softfloat.c:4819:
+return 1 << 31; // Integer indefinite value

ERROR: do not use C99 // comments
#37: FILE: fpu/softfloat.c:4851:
+return 1 << 31; // Integer indefinite value

ERROR: do not use C99 // comments
#48: FILE: fpu/softfloat.c:4901:
+return 1 << 63; // Integer indefinite value (64-bit)

ERROR: do not use C99 // comments
#59: FILE: fpu/softfloat.c:4946:
+return 1 << 63; // Integer indefinite value (64-bit)

total: 4 errors, 0 warnings, 171 lines checked

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

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

[Qemu-devel] [PATCH v3] fpu: add mechanism to check for invalid long double formats

[Andrew Dutcher]

All operations that take a floatx80 as an operand need to have their
inputs checked for malformed encodings. In all of these cases, use the
function floatx80_invalid_encoding to perform the check. If an invalid
operand is found, raise an invalid operation exception, and then return
either NaN (for fp-typed results) or the integer indefinite value (the
minimum representable signed integer value, for int-typed results).

Signed-off-by: Andrew Dutcher 
---

Version 3: Move from a control-flow macro to an explicit inline return,
add check to all the conversion operations.

 fpu/softfloat.c | 60 +
 include/fpu/softfloat.h | 15 +
 2 files changed, 75 insertions(+)

diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 9b1eccf..fd2f58d 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloat.c
@@ -4814,6 +4814,10 @@ int32_t floatx80_to_int32(floatx80 a, float_status 
*status)
 int32_t aExp, shiftCount;
 uint64_t aSig;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return 1 << 31; // Integer indefinite value
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -4842,6 +4846,10 @@ int32_t floatx80_to_int32_round_to_zero(floatx80 a, 
float_status *status)
 uint64_t aSig, savedASig;
 int32_t z;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return 1 << 31; // Integer indefinite value
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -4888,6 +4896,10 @@ int64_t floatx80_to_int64(floatx80 a, float_status 
*status)
 int32_t aExp, shiftCount;
 uint64_t aSig, aSigExtra;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return 1 << 63; // Integer indefinite value (64-bit)
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -4929,6 +4941,10 @@ int64_t floatx80_to_int64_round_to_zero(floatx80 a, 
float_status *status)
 uint64_t aSig;
 int64_t z;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return 1 << 63; // Integer indefinite value (64-bit)
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -4971,6 +4987,10 @@ float32 floatx80_to_float32(floatx80 a, float_status 
*status)
 int32_t aExp;
 uint64_t aSig;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return float32_default_nan(status);
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -4999,6 +5019,10 @@ float64 floatx80_to_float64(floatx80 a, float_status 
*status)
 int32_t aExp;
 uint64_t aSig, zSig;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return float64_default_nan(status);
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -5027,6 +5051,10 @@ float128 floatx80_to_float128(floatx80 a, float_status 
*status)
 int aExp;
 uint64_t aSig, zSig0, zSig1;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return float128_default_nan(status);
+}
 aSig = extractFloatx80Frac( a );
 aExp = extractFloatx80Exp( a );
 aSign = extractFloatx80Sign( a );
@@ -5052,6 +5080,10 @@ floatx80 floatx80_round_to_int(floatx80 a, float_status 
*status)
 uint64_t lastBitMask, roundBitsMask;
 floatx80 z;
 
+if (floatx80_invalid_encoding(a)) {
+float_raise(float_flag_invalid, status);
+return floatx80_default_nan(status);
+}
 aExp = extractFloatx80Exp( a );
 if ( 0x403E <= aExp ) {
 if ( ( aExp == 0x7FFF ) && (uint64_t) ( extractFloatx80Frac( a )<<1 ) 
) {
@@ -5279,6 +5311,10 @@ floatx80 floatx80_add(floatx80 a, floatx80 b, 
float_status *status)
 {
 flag aSign, bSign;
 
+if (floatx80_invalid_encoding(a) || floatx80_invalid_encoding(b)) {
+float_raise(float_flag_invalid, status);
+return floatx80_default_nan(status);
+}
 aSign = extractFloatx80Sign( a );
 bSign = extractFloatx80Sign( b );
 if ( aSign == bSign ) {
@@ -5300,6 +5336,10 @@ floatx80 floatx80_sub(floatx80 a, floatx80 b, 
float_status *status)
 {
 flag aSign, bSign;
 
+if (floatx80_invalid_encoding(a) || floatx80_invalid_encoding(b)) {
+float_raise(float_flag_invalid, status);
+return floatx80_default_nan(status);
+}
 aSign = extractFloatx80Sign( a );
 bSign = extractFloatx80Sign( b );
 if ( aSign == bSign ) {
@@ -5323,6 +5363,10 @@ 

Re: [Qemu-devel] [PATCH v3] ui/cocoa.m: Make a better about dialog

[Peter Maydell]

On 29 July 2016 at 16:16, Programmingkid  wrote:
> The about dialog in QEMU on Mac OS X is very plain and unhelpful. This patch
> makes the about dialog look a lot better and have some descriptive information
> on what version of QEMU the user is running.
>
> Signed-off-by: John Arbuckle 

Thanks; this patch looks pretty good. I have a couple of minor
changes to suggest below.

Incidentally, while I was testing this I noticed that we
don't display the right icon for the "do you really
want to quit" alert box, but that's a separate bug.

> ---
> version 3 changes:
> Removed buffer related code
>
> version 2 changes:
> Added QEMU version to the version label
>
>  ui/cocoa.m | 107 
> +++--
>  1 file changed, 104 insertions(+), 3 deletions(-)
>
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index 36c6bf0..e17401b 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -34,6 +34,7 @@
>  #include "qmp-commands.h"
>  #include "sysemu/blockdev.h"
>  #include 
> +#include "qemu-version.h"

Could you put this above the Carbon.h include so we have all
our qemu-local #includes in one place in the file, please?

>  #ifndef MAC_OS_X_VERSION_10_5
>  #define MAC_OS_X_VERSION_10_5 1050
> @@ -63,7 +64,7 @@ typedef struct {
>  int bitsPerPixel;
>  } QEMUScreen;
>
> -NSWindow *normalWindow;
> +NSWindow *normalWindow, *about_window;
>  static DisplayChangeListener *dcl;
>  static int last_buttons;
>
> @@ -670,7 +671,9 @@ QemuCocoaView *cocoaView;
>  case NSLeftMouseUp:
>  mouse_event = true;
>  if (!isMouseGrabbed && [self screenContainsPoint:p]) {
> -[self grabMouse];
> +if([[self window] isKeyWindow]) {
> +[self grabMouse];
> +}
>  }
>  break;
>  case NSRightMouseUp:
> @@ -824,6 +827,8 @@ QemuCocoaView *cocoaView;
>  - (void)changeDeviceMedia:(id)sender;
>  - (BOOL)verifyQuit;
>  - (void)openDocumentation:(NSString *)filename;
> +- (IBAction) do_about_menu_item: (id) sender;
> +- (void)make_about_window;
>  @end
>
>  @implementation QemuCocoaAppController
> @@ -876,6 +881,7 @@ QemuCocoaView *cocoaView;
>  supportedImageFileTypes = [NSArray arrayWithObjects: @"img", @"iso", 
> @"dmg",
>   @"qcow", @"qcow2", @"cloop", @"vmdk", 
> @"cdr",
>nil];
> +[self make_about_window];
>  }
>  return self;
>  }
> @@ -1138,6 +1144,101 @@ QemuCocoaView *cocoaView;
>  }
>  }
>
> +/* The action method for the About menu item */
> +- (IBAction) do_about_menu_item: (id) sender
> +{
> +[about_window makeKeyAndOrderFront: nil];
> +}
> +
> +/* Create and display the about dialog */
> +- (void)make_about_window
> +{
> +/* Make the window */
> +int x = 0, y = 0, about_width = 400, about_height = 200;
> +NSRect window_rect = NSMakeRect(x, y, about_width, about_height);
> +about_window = [[NSWindow alloc] initWithContentRect:window_rect
> +styleMask:NSTitledWindowMask | NSClosableWindowMask |
> +NSMiniaturizableWindowMask
> +backing:NSBackingStoreBuffered
> +defer:NO];
> +[about_window setTitle: @"About"];
> +[about_window setReleasedWhenClosed: NO];
> +[about_window center];
> +NSView *superView = [about_window contentView];
> +
> +/* Create the dimensions of the picture */
> +int picture_width = 80, picture_height = 80;
> +x = (about_width - picture_width)/2;
> +y = about_height - picture_height - 10;
> +NSRect picture_rect = NSMakeRect(x, y, picture_width, picture_height);
> +
> +/* Get the path to the QEMU binary */
> +NSString *binary_name = [NSString stringWithCString: gArgv[0]
> +  encoding: NSASCIIStringEncoding];
> +binary_name = [binary_name lastPathComponent];
> +NSString *program_path = [[NSString alloc] initWithFormat: @"%@/%@",
> +[[NSBundle mainBundle] bundlePath], binary_name];
> +
> +/* Make the picture of QEMU */
> +NSImageView *picture_view = [[NSImageView alloc] initWithFrame:
> + picture_rect];
> +NSImage *qemu_image = [[NSWorkspace sharedWorkspace] iconForFile:
> + program_path];
> +[picture_view setImage: qemu_image];
> +[picture_view setImageScaling: NSScaleToFit];

This causes a deprecation warning in 10.10 I'm afraid:

/Users/pm215/src/qemu/ui/cocoa.m:1188:36: warning: 'NSScaleToFit' is
deprecated: first deprecated in OS X 10.10 - Use
NSImageScaleAxesIndependently instead
  [-Wdeprecated-declarations]
[picture_view setImageScaling: NSScaleToFit];
   ^
/System/Library/Frameworks/AppKit.framework/Headers/NSCell.h:64:5:
note: 'NSScaleToFit' has been 

Re: [Qemu-devel] [PATCH] Revert "vhost-user: Attempt to fix a race with set_mem_table."

[Michael S. Tsirkin]

On Mon, Aug 15, 2016 at 04:15:08PM +0100, Peter Maydell wrote:
> On 15 August 2016 at 14:35, Michael S. Tsirkin  wrote:
> > This reverts commit 28ed5ef16384f12500abd3647973ee21b03cbe23.
> >
> > I still think it's the right thing to do, but
> > tests have been failing sporadically.
> >
> > Revert for now, and hope to fix it before the release.
> >
> > Cc: Prerna Saxena 
> > Cc: Peter Maydell 
> > Cc: Marc-André Lureau 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> 
> Applied, thanks. I found my clang-on-x86-64 Linux Ubuntu xenial
> build would hang in vhost-user/read-guest-mem after 10 or
> so iterations, but with this revert applied it seems fine,
> so I think this commit was definitely the culprit.
> 
> -- PMM

That's nice for the RC, but I think we do want to
have the underlying issue fixed down the road.
Prerna, Marc André - any chance you could try
reproducing on an ubuntu guest?

In particular to make sure the issue whatever it is
will not tigger once clients negotiate the
new feature bit.

-- 
MST

Re: [Qemu-devel] [PATCH V1 1/1] arm64: Add an option to turn on/off host-backed vPMU support

[Wei Huang]

On 08/15/2016 05:09 AM, Andrew Jones wrote:
> On Sat, Aug 13, 2016 at 12:52:50AM -0500, Wei Huang wrote:
>> This patch adds a pmu=[on/off] option to enable/disable host vPMU
>> support in guest VM. There are several reasons to justify this option.
>> First, host-backed vPMU can be problematic for cross-migration between
>> different SoC as perf counters are architecture-dependent. It is more
>> flexible to have an option to turn it on/off. Secondly this option
>> matches the "pmu" option as supported in libvirt tool.
>>
>> Note that, like "has_el3", the "pmu" option is only made available on
>> CPUs that support host-backed vPMU. They include:
>> * cortex-a53 + kvm
>> * cortex-a57 + kvm
>> * host + kvm
>> This option is removed in other configs where it doesn't make sense
>> (e.g. cortex-a57 + TCG); and the default pmu support is off. This patch
> 
> Some of the PMU registers are already emulated with TCG. While it
> doesn't make much sense to use perf counters in a TCG guest for
> measuring anything, it may have merit for emulation completeness
> and debug. With that in mind, then I think we need to add the PMU
> feature to all processors that support it, and thus the 'has_pmu'

The TCG case you mentioned was one reason I changed the naming. The
existing "has_pmu" variable was introduced recently and it didn't cover
the case of TCG. Reading 5c0a3819, it is only turned on when KVM is
enabled and PMU_V3_extension is available. If we want to extend the
meaning of "has_pmu" for all PMU cases (i.e. KVM + TCG), we probably
need to address cases of has_pmu=ON + TCG=ON.

> name is better. As the feature is optional, I agree it does make
> sense that it's off by default, and only available with the pmu=on
> property.
> 
> I think there are more processors than just A53 and A57.

host-backed vPMU is only available on A53/A57/host. But TCG supports
more than A53/A57.

> 
>> has been tested under both DT/ACPI modes.
>>
>> Signed-off-by: Wei Huang 
>> ---
>>  hw/arm/virt-acpi-build.c |  2 +-
>>  hw/arm/virt.c|  2 +-
>>  target-arm/cpu.c | 13 +
>>  target-arm/cpu.h |  3 ++-
>>  target-arm/cpu64.c   |  6 ++
>>  target-arm/kvm64.c   | 10 +-
>>  6 files changed, 28 insertions(+), 8 deletions(-)
>>
>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
>> index 28fc59c..22fb9d9 100644
>> --- a/hw/arm/virt-acpi-build.c
>> +++ b/hw/arm/virt-acpi-build.c
>> @@ -540,7 +540,7 @@ build_madt(GArray *table_data, BIOSLinker *linker, 
>> VirtGuestInfo *guest_info)
>>  gicc->uid = i;
>>  gicc->flags = cpu_to_le32(ACPI_GICC_ENABLED);
>>  
>> -if (armcpu->has_pmu) {
>> +if (armcpu->has_host_pmu) {
>>  gicc->performance_interrupt = cpu_to_le32(PPI(VIRTUAL_PMU_IRQ));
>>  }
>>  }
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index a193b5a..4975f38 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -477,7 +477,7 @@ static void fdt_add_pmu_nodes(const VirtBoardInfo *vbi, 
>> int gictype)
>>  
>>  CPU_FOREACH(cpu) {
>>  armcpu = ARM_CPU(cpu);
>> -if (!armcpu->has_pmu ||
>> +if (!armcpu->has_host_pmu ||
>>  !kvm_arm_pmu_create(cpu, PPI(VIRTUAL_PMU_IRQ))) {
>>  return;
>>  }
>> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
>> index ce8b8f4..a527128 100644
>> --- a/target-arm/cpu.c
>> +++ b/target-arm/cpu.c
>> @@ -509,6 +509,10 @@ static Property arm_cpu_rvbar_property =
>>  static Property arm_cpu_has_el3_property =
>>  DEFINE_PROP_BOOL("has_el3", ARMCPU, has_el3, true);
>>  
>> +/* use property name "pmu" to match with other archs and libvirt */
>> +static Property arm_cpu_has_host_pmu_property =
>> +DEFINE_PROP_BOOL("pmu", ARMCPU, has_host_pmu, false);
>> +
>>  static Property arm_cpu_has_mpu_property =
>>  DEFINE_PROP_BOOL("has-mpu", ARMCPU, has_mpu, true);
>>  
>> @@ -552,6 +556,11 @@ static void arm_cpu_post_init(Object *obj)
>>  #endif
>>  }
>>  
>> +if (arm_feature(>env, ARM_FEATURE_HOST_PMU)) {
>> +qdev_property_add_static(DEVICE(obj), 
>> _cpu_has_host_pmu_property,
>> + _abort);
>> +}
>> +
>>  if (arm_feature(>env, ARM_FEATURE_MPU)) {
>>  qdev_property_add_static(DEVICE(obj), _cpu_has_mpu_property,
>>   _abort);
>> @@ -648,6 +657,10 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
>> **errp)
>>  cpu->id_aa64pfr0 &= ~0xf000;
>>  }
>>  
>> +if (!cpu->has_host_pmu) {
>> +unset_feature(env, ARM_FEATURE_HOST_PMU);
>> +}
> 
> I think this is the right approach. But we should add the feature to all
> processors that can have it, and then, after checking the property's
> value, we remove it when it's not desired.
> 
>> +
>>  if (!arm_feature(env, ARM_FEATURE_EL2)) {
>>  /* Disable the hypervisor feature bits in the processor feature
>>   

Re: [Qemu-devel] [PULL 0/2] xen-20160812-tag-2

[Peter Maydell]

On 13 August 2016 at 00:42, Stefano Stabellini  wrote:
> The following changes since commit 28b874429ba16e71e0caa46453f3a3e31efb3c51:
>
>   Merge remote-tracking branch 
> 'remotes/amit-migration/tags/migration-for-2.7-7' into staging (2016-08-11 
> 17:53:35 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160812-tag-2
>
> for you to fetch changes up to b7665c6027c972c23668ee74b878b5c617218514:
>
>   xen: handle inbound migration of VMs without ioreq server pages (2016-08-12 
> 16:38:30 -0700)
>
> 
> Xen 2016/08/12, fixed commit message
>
> 
> Cao jin (1):
>   Xen: fix converity warning of xen_pt_config_init()
>
> Paul Durrant (1):
>   xen: handle inbound migration of VMs without ioreq server pages

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Neo Jia]

On Mon, Aug 15, 2016 at 09:38:52AM +, Tian, Kevin wrote:
> > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > Sent: Saturday, August 13, 2016 8:37 AM
> > 
> > 
> > 
> > On 8/13/2016 2:46 AM, Alex Williamson wrote:
> > > On Sat, 13 Aug 2016 00:14:39 +0530
> > > Kirti Wankhede  wrote:
> > >
> > >> On 8/10/2016 12:30 AM, Alex Williamson wrote:
> > >>> On Thu, 4 Aug 2016 00:33:51 +0530
> > >>> Kirti Wankhede  wrote:
> > >>>
> > >>> This is used later by mdev_device_start() and mdev_device_stop() to get
> > >>> the parent_device so it can call the start and stop ops callbacks
> > >>> respectively.  That seems to imply that all of instances for a given
> > >>> uuid come from the same parent_device.  Where is that enforced?  I'm
> > >>> still having a hard time buying into the uuid+instance plan when it
> > >>> seems like each mdev_device should have an actual unique uuid.
> > >>> Userspace tools can figure out which uuids to start for a given user, I
> > >>> don't see much value in collecting them to instances within a uuid.
> > >>>
> > >>
> > >> Initially we started discussion with VM_UUID+instance suggestion, where
> > >> instance was introduced to support multiple devices in a VM.
> > >
> > > The instance number was never required in order to support multiple
> > > devices in a VM, IIRC this UUID+instance scheme was to appease NVIDIA
> > > management tools which wanted to re-use the VM UUID by creating vGPU
> > > devices with that same UUID and therefore associate udev events to a
> > > given VM.  Only then does an instance number become necessary since the
> > > UUID needs to be static for a vGPUs within a VM.  This has always felt
> > > like a very dodgy solution when we should probably just be querying
> > > libvirt to give us a device to VM association.
> 
> Agree with Alex here. We'd better not assume that UUID will be a VM_UUID
> for mdev in the basic design. It's bound to NVIDIA management stack too 
> tightly.
> 
> I'm OK to give enough flexibility for various upper level management stacks,
> e.g. instead of $UUID+INDEX style, would $UUID+STRING provide a better
> option where either UUID or STRING could be optional? Upper management 
> stack can choose its own policy to identify a mdev:
> 
> a) $UUID only, so each mdev is allocated with a unique UUID
> b) STRING only, which could be an index (0, 1, 2, ...), or any combination 
> (vgpu0, vgpu1, etc.)
> c) $UUID+STRING, where UUID could be a VM UUID, and STRING could be
> a numeric index
> 
> > >
> > >> 'mdev_create' creates device and 'mdev_start' is to commit resources of
> > >> all instances of similar devices assigned to VM.
> > >>
> > >> For example, to create 2 devices:
> > >> # echo "$UUID:0:params" > /sys/devices/../mdev_create
> > >> # echo "$UUID:1:params" > /sys/devices/../mdev_create
> > >>
> > >> "$UUID-0" and "$UUID-1" devices are created.
> > >>
> > >> Commit resources for above devices with single 'mdev_start':
> > >> # echo "$UUID" > /sys/class/mdev/mdev_start
> > >>
> > >> Considering $UUID to be a unique UUID of a device, we don't need
> > >> 'instance', so 'mdev_create' would look like:
> > >>
> > >> # echo "$UUID1:params" > /sys/devices/../mdev_create
> > >> # echo "$UUID2:params" > /sys/devices/../mdev_create
> > >>
> > >> where $UUID1 and $UUID2 would be mdev device's unique UUID and 'params'
> > >> would be vendor specific parameters.
> > >>
> > >> Device nodes would be created as "$UUID1" and "$UUID"
> > >>
> > >> Then 'mdev_start' would be:
> > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_start
> > >>
> > >> Similarly 'mdev_stop' and 'mdev_destroy' would be:
> > >>
> > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_stop
> > >
> > > I'm not sure a comma separated list makes sense here, for both
> > > simplicity in the kernel and more fine grained error reporting, we
> > > probably want to start/stop them individually.  Actually, why is it
> > > that we can't use the mediated device being opened and released to
> > > automatically signal to the backend vendor driver to commit and release
> > > resources? I don't fully understand why userspace needs this interface.
> 
> There is a meaningful use of start/stop interface, as required in live
> migration support. Such interface allows vendor driver to quiescent 
> mdev activity on source device before mdev hardware state is snapshot,
> and then resume mdev activity on dest device after its state is recovered.
> Intel has implemented experimental live migration support in KVMGT (soon
> to release), based on above two interfaces (plus another two to get/set
> mdev state).
> 
> > >
> > 
> > For NVIDIA vGPU solution we need to know all devices assigned to a VM in
> > one shot to commit resources of all vGPUs assigned to a VM along with
> > some common resources.
> 
> Kirti, can you elaborate the background about above one-shot commit
> requirement? It's hard to understand such a requirement. 
> 
> As I relied in another 

Re: [Qemu-devel] [PATCH for-2.7 0/4] virtio-balloon: fix stats vq migration

[Gaudenz Steinlin]

Stefan Hajnoczi  writes:

> Gaudenz Steinlin  reported that virtqueue_pop() terminates
> QEMU because the virtqueue size is exceeded following the CVE-2016-5403 fix.  
> I
> have been unable to reproduce this or understand the root cause by code
> inspection.  Along the way I did discover a few bugs in virtio-balloon and
> virtio code.
>
> Please see the individual patches for details.
>
> Gaudenz: If you can reproduce the bug you reported, please try again with 
> these
> patches applied.

As mentioned in the original thread I only tested on QEMU 2.0.0 so far.
I tried to apply your patches to this version, but did not succeed. I
could not apply the first patch in the series because the code changed
too much and with only the others applied QEMU failed to compile. I gave
up at that point.

Does it make sense at all to test these patches on 2.0.0? Ubuntu
reverted the problematic fix in their latest package update for trusty,
so my immediate problem is "solved". Is there a chance to get a fix for
CVE-2016-5403 that works on QEMU 2.0.0 without breaking migrations?

Best regards and thanks to all for the effort so far,
Gaudenz


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH for-2.7] pc-bios/optionrom: Fix OpenBSD build with better detection of linker emulation

[Brad Smith]

On 8/15/2016 1:26 PM, Peter Maydell wrote:


On 8 August 2016 at 17:11, Peter Maydell  wrote:

The various host OSes are irritatingly variable about the name
of the linker emulation we need to pass to ld's -m option to
build the i386 option ROMs. Instead of doing this via a
CONFIG ifdef, check in configure whether any of the emulation
names we know about will work and pass the right answer through
to the makefile. If we can't find one, we fall back to not trying
to build the option ROMs, in the same way we would for a non-x86
host platform.

This is in particular necessary to unbreak the build on OpenBSD,
since it wants a different answer to FreeBSD and we don't have
an existing CONFIG_ variable that distinguishes the two.

Signed-off-by: Peter Maydell 
---
This works for Linux and for the Windows builds; I don't have any
BSD systems to test it on. Brad and Sean, can I ask you to test this
on OpenBSD and FreeBSD, please?

(I think this is going to miss -rc2. Sorry about that; we'll
get OpenBSD builds fixed for -rc3.)

Applied to master (as-is, in the absence of a build check for
i386 OpenBSD; we can always add the elf_i386_obsd entry to the
list as a later patch, and if not then i386 is no worse off
than other non-x86-64 OpenBSD hosts: it just won't build the
option roms from source).

thanks
-- PMM

I am fine with that. Thank you.

Re: [Qemu-devel] [PATCH] test-logging: don't hard-code paths in /tmp

[Sascha Silbe]

Dear Peter,

Peter Maydell  writes:

> On 15 July 2016 at 17:24, Sascha Silbe  wrote:
[...]
>> Instead of hard-coding the paths, create a temporary directory using
>> g_dir_make_tmp() and clean it up afterwards.
>>
>> Fixes: f6880b7f ("qemu-log: support simple pid substitution for logs")
>> Signed-off-by: Sascha Silbe 
>
> Thanks for this patch -- I just noticed that the test was leaving
> temporary files not cleaned up, which brought me to this patch
> by searching the mail archives...

I have totally forgotten about it. Would probably have remembered the
next time "make check" failed on a shared machine. ;)


[tests/test-logging.c:test_parse_path()]
>> +gchar *plain_path = g_build_filename(tmp_path, "qemu.log", NULL);
>> +gchar *pid_infix_path = g_build_filename(tmp_path, "qemu-%d.log", NULL);
>> +gchar *pid_suffix_path = g_build_filename(tmp_path, "qemu.log.%d", 
>> NULL);
>> +gchar *double_pid_path = g_build_filename(tmp_path, "qemu-%d%d.log", 
>> NULL);
[...]
> This could usefully be refactored to have a helper function that does
> the g_build_filename/qemu_set_log_filename/g_free.

I wasn't sure about it but it actually ended up being a bit nicer than
what I had before.


>> +static void rmtree(gchar const *root)
[...]
> I don't really like spawning rm here for this. We know we
> don't have any subdirectories here so we can just
>gdir = g_dir_open(root, 0, NULL);
>for (;;) {
>const char *f = g_dir_read_name(gdir);
>if (!f) {
>break;
>}
>g_remove(f);
>}
>g_dir_close(gdir);
>g_rmdir(root);
>
> (add error handling to taste).

I don't really like the rm spawning solution either. But the above plus
error handling was a bit much for a single test for my taste.

Is there some place I could stick something like the above so it could
at least be reused by other tests in the future? (Even though I very
much hate the idea of implementing yet another rmtree()).


[...]
>>  int main(int argc, char **argv)
>>  {
>> +gchar *tmp_path = g_dir_make_tmp("qemu-test-logging.XX", NULL);
>
> Unfortunately g_dir_make_tmp() only came in in glib 2.30, and we have
> to be able to build with glib 2.22.

Bummer. The old interfaces were really awkward. Is there somewhere I
could put a compatibility wrapper, implementing g_dir_make_tmp() using
the old interfaces?


Thanks for the review!

Sascha
-- 
Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg
https://se-silbe.de/
USt-IdNr. DE281696641

Re: [Qemu-devel] [PATCH] target-arm: Fix lpae bit in FSR on an alignment fault

[Peter Maydell]

On 15 August 2016 at 18:48, Sergey Sorokin  wrote:
> If an alignment fault occurred and target EL is using AArch32,
> then DFSR/IFSR bit LPAE[9] must be set correctly.
>
> Signed-off-by: Sergey Sorokin 
> ---
>  target-arm/op_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c
> index 3e8588e..be27b21 100644
> --- a/target-arm/op_helper.c
> +++ b/target-arm/op_helper.c
> @@ -194,7 +194,7 @@ void arm_cpu_do_unaligned_access(CPUState *cs, vaddr 
> vaddr,
>   * the LPAE long descriptor format, or the short descriptor format
>   */
>  if (arm_s1_regime_using_lpae_format(env, cpu_mmu_index(env, false))) {
> -env->exception.fsr = 0x21;
> +env->exception.fsr = (1 << 9) | 0x21;
>  } else {
>  env->exception.fsr = 0x1;
>  }

Reviewed-by: Peter Maydell 

I've applied this to the set of target-arm patches I'm collecting for 2.8.

thanks
-- PMM

Re: [Qemu-devel] [PULL for-2.7 0/1] Tracing patches

[Peter Maydell]

On 12 August 2016 at 11:48, Stefan Hajnoczi  wrote:
> The following changes since commit 28b874429ba16e71e0caa46453f3a3e31efb3c51:
>
>   Merge remote-tracking branch 
> 'remotes/amit-migration/tags/migration-for-2.7-7' into staging (2016-08-11 
> 17:53:35 +0100)
>
> are available in the git repository at:
>
>   git://github.com/stefanha/qemu.git tags/tracing-pull-request
>
> for you to fetch changes up to e723b8710356163e0f1722b94f988a8ddf83f17a:
>
>   trace-events: fix first line comment in trace-events (2016-08-12 10:36:01 
> +0100)
>
> 
>

Applied, thanks.

-- PMM

[Qemu-devel] [PATCH] target-arm: Fix lpae bit in FSR on an alignment fault

[Sergey Sorokin]

If an alignment fault occurred and target EL is using AArch32,
then DFSR/IFSR bit LPAE[9] must be set correctly.

Signed-off-by: Sergey Sorokin 
---
 target-arm/op_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c
index 3e8588e..be27b21 100644
--- a/target-arm/op_helper.c
+++ b/target-arm/op_helper.c
@@ -194,7 +194,7 @@ void arm_cpu_do_unaligned_access(CPUState *cs, vaddr vaddr,
  * the LPAE long descriptor format, or the short descriptor format
  */
 if (arm_s1_regime_using_lpae_format(env, cpu_mmu_index(env, false))) {
-env->exception.fsr = 0x21;
+env->exception.fsr = (1 << 9) | 0x21;
 } else {
 env->exception.fsr = 0x1;
 }
-- 
1.9.3

Re: [Qemu-devel] [Xen-devel] [RFC for 2.8 0/3] Drop support for 64 bit guests on 32 bit hosts

[Stefano Stabellini]

On Wed, 10 Aug 2016, Gerd Hoffmann wrote:
> On Di, 2016-08-09 at 16:55 +0100, Alex Bennée wrote:
> > Hi,
> > 
> > I'm proposing for the 2.8 cycle we officially drop supporting 64 bit
> > guests on 32 bit hosts. For most of the KVM targets it doesn't make
> > any sense anyway and for TCG it makes things harder (e.g. supporting
> > 64 bit atomics on a 32 bit platform). I'm not actually convinced
> > things actually work if built or that anyone relies on these
> > combinations. Consider these patches a way of flushing any such users
> > out ;-)
> 
> Adding xen-devel to Cc.
> 
> 64bit xen hypervisor with 32bit dom0 running 32bit qemu, providing
> device emulation for 64bit dumUs at least used to be a common setup
> years ago.  I have my doubts this is still the case in recent xen
> versions, but I guess we better ask the Xen guys ...
> 
> Can anyone clarify?

Hi Gerd, thanks for CC'ing xen-devel on this.

Although 32bit Dom0 deployments are not as common as they used to be,
they are still certainly a valid scenario. However for them to work,
QEMU doesn't really need to support TCG 32bit on 64bit. QEMU when used
with Xen as accelerator doesn't actually do any CPU emulation; there was
even a proposal to remove the CPU emulation completely from Xen machines
a couple of years back
(http://marc.info/?l=qemu-devel=139051862915170=2). I hope this
helps.

Re: [Qemu-devel] [Qemu-arm] [PATCH v2] hw/vfio/platform: Add Qualcomm Technologies, Inc HIDMA device support

[Sinan Kaya]

On 8/15/2016 12:03 PM, Peter Maydell wrote:
> Just cc'ing Eric on his new email address...
> 
> thanks
> -- PMM
> 
> On 14 August 2016 at 16:42, Shanker Donthineni  
> wrote:
>> This patch introduces the Qualcomm Technologies, Inc HIDMA device and
>> allows passthrough the host HIDMA device to a guest machine using the
>> vfio-platform framework.
>>
>> A platform device tree node is created for the guest machine which
>> contains the compat string 'qcom,hidma-1.0', mmio regions, active high
>> SPIs, and an optional property dma-coherent.
>>
>> Signed-off-by: Vikram Sethi 
>> Signed-off-by: Shanker Donthineni 
>> ---
>> Changes sicnce v1:
>>   combined patches [v1 1/2] and [v1 2/2].
>>   added '#include "qemu/osdep.h'.
>>   changed compact string to 'qcom,hidma-1.0' to match the host driver.
>>   set dma-coherent property based on the IOMMU coherency status.
>>
>>  hw/arm/sysbus-fdt.c   | 67 
>> +++
>>  hw/vfio/Makefile.objs |  1 +
>>  hw/vfio/qcom-hidma.c  | 58 +
>>  include/hw/vfio/vfio-qcom-hidma.h | 50 +
>>  4 files changed, 176 insertions(+)
>>  create mode 100644 hw/vfio/qcom-hidma.c
>>  create mode 100644 include/hw/vfio/vfio-qcom-hidma.h
>>
>> diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
>> index 5debb33..bdf8cbb 100644
>> --- a/hw/arm/sysbus-fdt.c
>> +++ b/hw/arm/sysbus-fdt.c
>> @@ -27,6 +27,7 @@
>>  #include "qemu-common.h"
>>  #ifdef CONFIG_LINUX
>>  #include 
>> +#include 
>>  #endif
>>  #include "hw/arm/sysbus-fdt.h"
>>  #include "qemu/error-report.h"
>> @@ -36,6 +37,7 @@
>>  #include "hw/vfio/vfio-platform.h"
>>  #include "hw/vfio/vfio-calxeda-xgmac.h"
>>  #include "hw/vfio/vfio-amd-xgbe.h"
>> +#include "hw/vfio/vfio-qcom-hidma.h"
>>  #include "hw/arm/fdt.h"
>>
>>  /*
>> @@ -262,6 +264,70 @@ static int 
>> add_calxeda_midway_xgmac_fdt_node(SysBusDevice *sbdev, void *opaque)
>>  return 0;
>>  }
>>
>> +/**
>> + * add_qcom_hidma_fdt_node
>> + *
>> + * Generates a simple node with following properties:
>> + * compatible string, regs, active-high interrupts, and optional 
>> dma-coherent
>> + */
>> +static int add_qcom_hidma_fdt_node(SysBusDevice *sbdev, void *opaque)
>> +{
>> +VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
>> +struct VFIOGroup *group = vdev->vbasedev.group;
>> +VFIODevice *vbasedev = >vbasedev;
>> +PlatformBusFDTData *data = opaque;
>> +const char *parent_node = data->pbus_node_name;
>> +PlatformBusDevice *pbus = data->pbus;
>> +uint32_t *irq_attr, *reg_attr;
>> +uint64_t mmio_base, irq_number;
>> +void *fdt = data->fdt;
>> +int compat_str_len, i, ret;
>> +char *nodename;
>> +
>> +mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, 0);
>> +nodename = g_strdup_printf("%s/%s@%" PRIx64, parent_node,
>> +   vbasedev->name, mmio_base);
>> +assert(nodename);
>> +qemu_fdt_add_subnode(fdt, nodename);
>> +
>> +compat_str_len = strlen(vdev->compat) + 1;
>> +qemu_fdt_setprop(fdt, nodename, "compatible",
>> +  vdev->compat, compat_str_len);
>> +
>> +/* Check if the DMA cache coherency was enabled in IOMMU */
>> +ret = ioctl(group->container->fd, VFIO_CHECK_EXTENSION, 
>> VFIO_DMA_CC_IOMMU);
>> +if (ret > 0) {
>> +qemu_fdt_setprop(fdt, nodename, "dma-coherent", "", 0);
>> +}
>> +
>> +reg_attr = g_new(uint32_t, vbasedev->num_regions * 2);
>> +assert(reg_attr);
>> +for (i = 0; i < vbasedev->num_regions; i++) {
>> +mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, i);
>> +reg_attr[2 * i] = cpu_to_be32(mmio_base);
>> +reg_attr[2 * i + 1] = cpu_to_be32(
>> +memory_region_size(vdev->regions[i]->mem));
>> +}
>> +qemu_fdt_setprop(fdt, nodename, "reg", reg_attr,
>> + vbasedev->num_regions * 2 * sizeof(uint32_t));
>> +
>> +irq_attr = g_new(uint32_t, vbasedev->num_irqs * 3);
>> +assert(irq_attr);
>> +for (i = 0; i < vbasedev->num_irqs; i++) {
>> +irq_number = platform_bus_get_irqn(pbus, sbdev , i)
>> + + data->irq_start;
>> +irq_attr[3 * i] = cpu_to_be32(GIC_FDT_IRQ_TYPE_SPI);
>> +irq_attr[3 * i + 1] = cpu_to_be32(irq_number);
>> +irq_attr[3 * i + 2] = cpu_to_be32(GIC_FDT_IRQ_FLAGS_LEVEL_HI);
>> +}
>> +qemu_fdt_setprop(fdt, nodename, "interrupts",
>> + irq_attr, vbasedev->num_irqs * 3 * sizeof(uint32_t));
>> +g_free(irq_attr);
>> +g_free(reg_attr);
>> +g_free(nodename);
>> +return 0;
>> +}
>> +
>>  /* AMD xgbe properties whose values are copied/pasted from host */
>>  static HostProperty amd_xgbe_copied_properties[] = {
>>  {"compatible", false},
>> @@ -420,6 +486,7 @@ static const NodeCreationPair add_fdt_node_functions[] = 

Re: [Qemu-devel] [PATCH for-2.7] pc-bios/optionrom: Fix OpenBSD build with better detection of linker emulation

[Peter Maydell]

On 8 August 2016 at 17:11, Peter Maydell  wrote:
> The various host OSes are irritatingly variable about the name
> of the linker emulation we need to pass to ld's -m option to
> build the i386 option ROMs. Instead of doing this via a
> CONFIG ifdef, check in configure whether any of the emulation
> names we know about will work and pass the right answer through
> to the makefile. If we can't find one, we fall back to not trying
> to build the option ROMs, in the same way we would for a non-x86
> host platform.
>
> This is in particular necessary to unbreak the build on OpenBSD,
> since it wants a different answer to FreeBSD and we don't have
> an existing CONFIG_ variable that distinguishes the two.
>
> Signed-off-by: Peter Maydell 
> ---
> This works for Linux and for the Windows builds; I don't have any
> BSD systems to test it on. Brad and Sean, can I ask you to test this
> on OpenBSD and FreeBSD, please?
>
> (I think this is going to miss -rc2. Sorry about that; we'll
> get OpenBSD builds fixed for -rc3.)

Applied to master (as-is, in the absence of a build check for
i386 OpenBSD; we can always add the elf_i386_obsd entry to the
list as a later patch, and if not then i386 is no worse off
than other non-x86-64 OpenBSD hosts: it just won't build the
option roms from source).

thanks
-- PMM

Re: [Qemu-devel] [PATCH V1 1/1] arm64: Add an option to turn on/off host-backed vPMU support

[Andrea Bolognani]

On Mon, 2016-08-15 at 11:12 -0500, Wei Huang wrote:
> > Did you already try driving this with libvirt? It should work
> > out of the box.
> > 
> > If you haven't, I will do it :)
> 
> No, I haven't. All tests were done based on command line to QEMU. :-)

Fair enough :)

I did some testing on my own using libvirt to drive a QEMU
binary that included your patch, and it looks like everything
is working as expected: if I turn PMU on using the appropriate
XML element () I can access the performance
counters from inside the guest; if I disable it explicitly or
don't enable it, I can't.

The host-side testing involved making sure the 'pmu' flag
was passed, or not passed, to QEMU and the value, if any,
matched the guest XML.

The guest-side testing involved running

  $ dmesg | grep -i pmu
  $ perf list | grep 'Hardware event'

and making sure some output was returned in both cases, and
making sure the 'instructions' counter was not marked as '' in the output of

  $ perf stat true

If the kind of testing I performed is not good enough, please
let me know and I'll do another round.

This was tested only with  (the
libvirt equivalent of -cpu host), because the aarch64 CPU
driver in libvirt is not currently capable of handling other
CPU models for KVM guests.

I also verified that TCG guests didn't accept the 'pmu' flag.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [PATCH V1 1/1] arm64: Add an option to turn on/off host-backed vPMU support

[Andrea Bolognani]

On Mon, 2016-08-15 at 12:09 +0200, Andrew Jones wrote:
> Hmm... so now if the user doesn't specify pmu=on (off by default) then we
> silently disable it (I think that's a 2.6 compat issue), and if they do
> specify pmu=on, but KVM doesn't support it, then it's silently disabled,
> which isn't nice. I think QEMU should error out in that case, explaining
> that the user specified incompatible options, i.e. they selected accel=kvm
> and pmu=on, but their KVM version (or cpu model) doesn't support PMU
> emulation.

I agree. Asking qemu to provide a feature that it can't provide
should definitely result in a big fat error.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [V2 0/6] AMD IOMMU interrupt remapping

[David Kiarie]

On Mon, Aug 15, 2016 at 7:32 PM, David Kiarie 
wrote:

> Hello all,
>
> The following patchset implements AMD-Vi interrupt remapping logic and
> hooks it onto existing IR infrastucture.
>
> I have bundled this patchset together with the "Explicit SID for
> IOAPIC"."Explicit SID for IOAPIC" functions to
> affiliate MSI routes with a requester ID and a PCI device if present which
> enables platform devices like IOAPIC to
> make interrupt requests using an explicit SID as required by both VT-d and
> AMD-Vi.
>

This has a dependency on AMD IOMMU patchset but for quick testing
https://github.com/aslaq/qemu IR


>
> David Kiarie (6):
>   hw/msi: Allow platform devices to use explicit SID
>   hw/i386: enforce SID verification
>   hw/iommu: Prepare for AMD IOMMU interrupt remapping
>   hw/iommu: AMD IOMMU interrupt remapping
>   hw/acpi: report IOAPIC on IVRS
>   hw/iommu: share common code between IOMMUs
>
>  hw/i386/acpi-build.c  |   2 +
>  hw/i386/amd_iommu.c   | 244 ++
> +++-
>  hw/i386/amd_iommu.h   |  40 +++
>  hw/i386/intel_iommu.c |  89 +++---
>  hw/i386/kvm/pci-assign.c  |  12 +-
>  hw/i386/x86-iommu.c   |   8 ++
>  hw/intc/ioapic.c  |  25 +++-
>  hw/misc/ivshmem.c |   6 +-
>  hw/vfio/pci.c |   6 +-
>  hw/virtio/virtio-pci.c|   7 +-
>  include/hw/i386/ioapic_internal.h |   1 +
>  include/hw/i386/x86-iommu.h   |   1 +
>  include/sysemu/kvm.h  |  25 ++--
>  kvm-all.c |  10 +-
>  kvm-stub.c|   5 +-
>  target-i386/kvm.c |  15 ++-
>  16 files changed, 386 insertions(+), 110 deletions(-)
>
> --
> 2.1.4
>
>

[Qemu-devel] [V2 4/6] hw/iommu: AMD IOMMU interrupt remapping

[David Kiarie]

Introduce AMD IOMMU interrupt remapping and hook it onto
the existing interrupt remapping infrastructure

Signed-off-by: David Kiarie 
---
 hw/i386/amd_iommu.c | 244 +++-
 hw/i386/amd_iommu.h |   4 +-
 2 files changed, 243 insertions(+), 5 deletions(-)

diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 19da365..08d6dae 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -18,11 +18,10 @@
  * with this program; if not, see .
  *
  * Cache implementation inspired by hw/i386/intel_iommu.c
+ *
  */
 #include "qemu/osdep.h"
-#include 
-#include "hw/pci/msi.h"
-#include "hw/i386/pc.h"
+#include "qemu/error-report.h"
 #include "hw/i386/amd_iommu.h"
 #include "hw/pci/pci_bus.h"
 #include "trace.h"
@@ -270,6 +269,31 @@ typedef struct QEMU_PACKED {
 #endif /* __BIG_ENDIAN_BITFIELD */
 } CMDCompletePPR;
 
+typedef union IRTE {
+struct {
+#ifdef HOST_WORDS_BIGENDIAN
+uint32_t destination:8;
+uint32_t rsvd_1:1;
+uint32_t dm:1;
+uint32_t rq_eoi:1;
+uint32_t int_type:3;
+uint32_t no_fault:1;
+uint32_t valid:1;
+#else
+uint32_t valid:1;
+uint32_t no_fault:1;
+uint32_t int_type:3;
+uint32_t rq_eoi:1;
+uint32_t dm:1;
+uint32_t rsvd_1:1;
+uint32_t destination:8;
+#endif
+uint32_t vector:8;
+uint32_t rsvd_2:8;
+} bits;
+uint32_t data;
+} IRTE;
+
 /* configure MMIO registers at startup/reset */
 static void amdvi_set_quad(AMDVIState *s, hwaddr addr, uint64_t val,
uint64_t romask, uint64_t w1cmask)
@@ -660,6 +684,11 @@ static void amdvi_inval_inttable(AMDVIState *s, 
CMDInvalIntrTable *inval)
 amdvi_log_illegalcom_error(s, inval->type, s->cmdbuf + s->cmdbuf_head);
 return;
 }
+
+if (s->ir_cache) {
+x86_iommu_iec_notify_all(X86_IOMMU_DEVICE(s), true, 0, 0);
+}
+
 trace_amdvi_intr_inval();
 }
 
@@ -1221,6 +1250,197 @@ static IOMMUTLBEntry amdvi_translate(MemoryRegion 
*iommu, hwaddr addr,
 return ret;
 }
 
+static inline int amdvi_ir_handle_non_vectored(MSIMessage *src,
+   MSIMessage *dst, uint8_t bitpos,
+   uint64_t dte)
+{
+if ((dte & (1UL << bitpos))) {
+/* passing interrupt enabled */
+memcpy(dst, src, sizeof(*dst));
+} else {
+/* should be target aborted */
+return -AMDVI_TARGET_ABORT;
+}
+return 0;
+}
+
+static int amdvi_remap_ir_intctl(uint64_t dte, IRTE irte,
+ MSIMessage *src, MSIMessage *dst)
+{
+int ret = 0;
+
+switch ((dte >> AMDVI_DTE_INTCTL_RSHIFT) & 3UL) {
+case AMDVI_INTCTL_PASS:
+/* pass */
+memcpy(dst, src, sizeof(*dst));
+break;
+case AMDVI_INTCTL_REMAP:
+/* remap */
+if (irte.bits.valid) {
+/* LOCAL APIC address */
+dst->address = AMDVI_LOCAL_APIC_ADDR;
+/* destination mode */
+dst->address |= ((uint64_t)irte.bits.dm) <<
+AMDVI_MSI_ADDR_DM_RSHIFT;
+/* RH */
+dst->address |= ((uint64_t)irte.bits.rq_eoi) <<
+AMDVI_MSI_ADDR_RH_RSHIFT;
+/* Destination ID */
+dst->address |= ((uint64_t)irte.bits.destination) <<
+AMDVI_MSI_ADDR_DEST_RSHIFT;
+/* construct data - vector */
+dst->data |= irte.bits.vector;
+/* Interrupt type */
+dst->data |= ((uint64_t)irte.bits.int_type) <<
+ AMDVI_MSI_DATA_DM_RSHIFT;
+} else  {
+ret = -AMDVI_TARGET_ABORT;
+}
+break;
+case AMDVI_INTCTL_ABORT:
+case AMDVI_INTCTL_RSVD:
+ret = -AMDVI_TARGET_ABORT;
+}
+return ret;
+}
+
+static int amdvi_irte_get(AMDVIState *s, MSIMessage *src, IRTE *irte,
+  uint64_t *dte, uint16_t devid)
+{
+uint64_t irte_root, offset = devid * AMDVI_DEVTAB_ENTRY_SIZE,
+ ir_table_size;
+
+irte_root = dte[2] & AMDVI_IRTEROOT_MASK;
+offset = (src->data & AMDVI_IRTE_INDEX_MASK) << 2;
+ir_table_size = 1UL << (dte[2] & AMDVI_IR_TABLE_SIZE_MASK);
+/* enforce IR table size */
+if (offset > (ir_table_size * AMDVI_DEFAULT_IRTE_SIZE)) {
+trace_amdvi_invalid_irte_entry(offset, ir_table_size);
+return -AMDVI_TARGET_ABORT;
+}
+/* read IRTE */
+if (dma_memory_read(_space_memory, irte_root + offset,
+irte, sizeof(*irte))) {
+trace_amdvi_irte_get_fail(irte_root, offset);
+return -AMDVI_DEV_TAB_HW;
+}
+return 0;
+}
+
+static int amdvi_int_remap(X86IOMMUState *iommu, MSIMessage *src,
+   MSIMessage *dst, uint16_t sid)
+{
+trace_amdvi_ir_request(src->data, src->address, sid);
+
+

[Qemu-devel] [V2 5/6] hw/acpi: report IOAPIC on IVRS

[David Kiarie]

Report IOAPIC via IVRS which effectively allows linux AMD-Vi
driver to enable interrupt remapping

Signed-off-by: David Kiarie 
---
 hw/i386/acpi-build.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 49bd183..c2559ff 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2615,6 +2615,8 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker)
  *   Refer to Spec - Table 95:IVHD Device Entry Type Codes(4-byte)
  */
 build_append_int_noprefix(table_data, 0x001, 4);
+/* IOAPIC represented as an 8-byte entry. Spec v2.62 Tables 97 */
+build_append_int_noprefix(table_data, 0x0100a000cf48, 8);
 
 build_header(linker, table_data, (void *)(table_data->data + iommu_start),
  "IVRS", table_data->len - iommu_start, 1, NULL, NULL);
-- 
2.1.4

[Qemu-devel] [V2 2/6] hw/i386: enforce SID verification

[David Kiarie]

Platform device are now able to make interrupt request with
explicit SIDs hence we can safely expect triggered AddressSpace ID
to match the requesting ID

Signed-off-by: David Kiarie 
---
 hw/i386/intel_iommu.c | 77 ++-
 1 file changed, 39 insertions(+), 38 deletions(-)

diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 496d836..e4bad6a 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -2043,43 +2043,41 @@ static int vtd_irte_get(IntelIOMMUState *iommu, 
uint16_t index,
 return -VTD_FR_IR_IRTE_RSVD;
 }
 
-if (sid != X86_IOMMU_SID_INVALID) {
-/* Validate IRTE SID */
-source_id = le32_to_cpu(entry->irte.source_id);
-switch (entry->irte.sid_vtype) {
-case VTD_SVT_NONE:
-VTD_DPRINTF(IR, "No SID validation for IRTE index %d", index);
-break;
-
-case VTD_SVT_ALL:
-mask = vtd_svt_mask[entry->irte.sid_q];
-if ((source_id & mask) != (sid & mask)) {
-VTD_DPRINTF(GENERAL, "SID validation for IRTE index "
-"%d failed (reqid 0x%04x sid 0x%04x)", index,
-sid, source_id);
-return -VTD_FR_IR_SID_ERR;
-}
-break;
+/* Validate IRTE SID */
+source_id = le32_to_cpu(entry->irte.source_id);
+switch (entry->irte.sid_vtype) {
+case VTD_SVT_NONE:
+VTD_DPRINTF(IR, "No SID validation for IRTE index %d", index);
+break;
 
-case VTD_SVT_BUS:
-bus_max = source_id >> 8;
-bus_min = source_id & 0xff;
-bus = sid >> 8;
-if (bus > bus_max || bus < bus_min) {
-VTD_DPRINTF(GENERAL, "SID validation for IRTE index %d "
-"failed (bus %d outside %d-%d)", index, bus,
-bus_min, bus_max);
-return -VTD_FR_IR_SID_ERR;
-}
-break;
+case VTD_SVT_ALL:
+mask = vtd_svt_mask[entry->irte.sid_q];
+if ((source_id & mask) != (sid & mask)) {
+VTD_DPRINTF(GENERAL, "SID validation for IRTE index "
+"%d failed (reqid 0x%04x sid 0x%04x)", index,
+sid, source_id);
+return -VTD_FR_IR_SID_ERR;
+}
+break;
 
-default:
-VTD_DPRINTF(GENERAL, "Invalid SVT bits (0x%x) in IRTE index "
-"%d", entry->irte.sid_vtype, index);
-/* Take this as verification failure. */
+case VTD_SVT_BUS:
+bus_max = source_id >> 8;
+bus_min = source_id & 0xff;
+bus = sid >> 8;
+if (bus > bus_max || bus < bus_min) {
+VTD_DPRINTF(GENERAL, "SID validation for IRTE index %d "
+"failed (bus %d outside %d-%d)", index, bus,
+bus_min, bus_max);
 return -VTD_FR_IR_SID_ERR;
-break;
 }
+break;
+
+default:
+VTD_DPRINTF(GENERAL, "Invalid SVT bits (0x%x) in IRTE index "
+"%d", entry->irte.sid_vtype, index);
+/* Take this as verification failure. */
+return -VTD_FR_IR_SID_ERR;
+break;
 }
 
 return 0;
@@ -2252,14 +2250,17 @@ static MemTxResult vtd_mem_ir_write(void *opaque, 
hwaddr addr,
 {
 int ret = 0;
 MSIMessage from = {}, to = {};
-uint16_t sid = X86_IOMMU_SID_INVALID;
+VTDAddressSpace *as = opaque;
+uint16_t sid = PCI_BUILD_BDF(pci_bus_num(as->bus), as->devfn);
 
 from.address = (uint64_t) addr + VTD_INTERRUPT_ADDR_FIRST;
 from.data = (uint32_t) value;
 
-if (!attrs.unspecified) {
-/* We have explicit Source ID */
-sid = attrs.requester_id;
+if (attrs.requester_id != sid) {
+VTD_DPRINTF(GENERAL, "int remap request for sid 0x%04x"
+" requester_id 0x%04x couldn't be verified",
+sid, attrs.requester_id);
+return MEMTX_ERROR;
 }
 
 ret = vtd_interrupt_remap_msi(opaque, , , sid);
@@ -2325,7 +2326,7 @@ VTDAddressSpace *vtd_find_add_as(IntelIOMMUState *s, 
PCIBus *bus, int devfn)
 memory_region_init_iommu(_dev_as->iommu, OBJECT(s),
  >iommu_ops, "intel_iommu", UINT64_MAX);
 memory_region_init_io(_dev_as->iommu_ir, OBJECT(s),
-  _mem_ir_ops, s, "intel_iommu_ir",
+  _mem_ir_ops, vtd_dev_as, "intel_iommu_ir",
   VTD_INTERRUPT_ADDR_SIZE);
 memory_region_add_subregion(_dev_as->iommu, 
VTD_INTERRUPT_ADDR_FIRST,
 _dev_as->iommu_ir);
-- 
2.1.4

[Qemu-devel] [V2 6/6] hw/iommu: share common code between IOMMUs

[David Kiarie]

Enabling interrupt remapping with kernel_irqchip=on should result
in an error for both VT-d and AMD-Vi

Signed-off-by: David Kiarie 
---
 hw/i386/intel_iommu.c | 9 -
 hw/i386/x86-iommu.c   | 8 
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index e4bad6a..bf86dcc 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -30,7 +30,6 @@
 #include "hw/boards.h"
 #include "hw/i386/x86-iommu.h"
 #include "hw/pci-host/q35.h"
-#include "sysemu/kvm.h"
 
 /*#define DEBUG_INTEL_IOMMU*/
 #ifdef DEBUG_INTEL_IOMMU
@@ -2472,14 +2471,6 @@ static void vtd_realize(DeviceState *dev, Error **errp)
 Q35_PSEUDO_DEVFN_IOAPIC);
 /* Pseudo address space under root PCI bus. */
 pcms->ioapic_as = vtd_host_dma_iommu(bus, s, Q35_PSEUDO_DEVFN_IOAPIC);
-
-/* Currently Intel IOMMU IR only support "kernel-irqchip={off|split}" */
-if (x86_iommu->intr_supported && kvm_irqchip_in_kernel() &&
-!kvm_irqchip_is_split()) {
-error_report("Intel Interrupt Remapping cannot work with "
- "kernel-irqchip=on, please use 'split|off'.");
-exit(1);
-}
 }
 
 static void vtd_class_init(ObjectClass *klass, void *data)
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index 2278af7..66510f7 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -21,6 +21,7 @@
 #include "hw/sysbus.h"
 #include "hw/boards.h"
 #include "hw/i386/x86-iommu.h"
+#include "sysemu/kvm.h"
 #include "qemu/error-report.h"
 #include "trace.h"
 
@@ -84,6 +85,13 @@ static void x86_iommu_realize(DeviceState *dev, Error **errp)
 if (x86_class->realize) {
 x86_class->realize(dev, errp);
 }
+/* Currently IOMMU IR only support "kernel-irqchip={off|split}" */
+if (x86_iommu->intr_supported && kvm_irqchip_in_kernel() &&
+!kvm_irqchip_is_split()) {
+error_report("Interrupt Remapping cannot work with "
+ "kernel-irqchip=on, please use 'split|off'.");
+exit(1);
+}
 
 x86_iommu_set_default(X86_IOMMU_DEVICE(dev));
 }
-- 
2.1.4

[Qemu-devel] [V2 0/6] AMD IOMMU interrupt remapping

[David Kiarie]

Hello all,

The following patchset implements AMD-Vi interrupt remapping logic and hooks it 
onto existing IR infrastucture.

I have bundled this patchset together with the "Explicit SID for 
IOAPIC"."Explicit SID for IOAPIC" functions to 
affiliate MSI routes with a requester ID and a PCI device if present which 
enables platform devices like IOAPIC to
make interrupt requests using an explicit SID as required by both VT-d and 
AMD-Vi.

David Kiarie (6):
  hw/msi: Allow platform devices to use explicit SID
  hw/i386: enforce SID verification
  hw/iommu: Prepare for AMD IOMMU interrupt remapping
  hw/iommu: AMD IOMMU interrupt remapping
  hw/acpi: report IOAPIC on IVRS
  hw/iommu: share common code between IOMMUs

 hw/i386/acpi-build.c  |   2 +
 hw/i386/amd_iommu.c   | 244 +-
 hw/i386/amd_iommu.h   |  40 +++
 hw/i386/intel_iommu.c |  89 +++---
 hw/i386/kvm/pci-assign.c  |  12 +-
 hw/i386/x86-iommu.c   |   8 ++
 hw/intc/ioapic.c  |  25 +++-
 hw/misc/ivshmem.c |   6 +-
 hw/vfio/pci.c |   6 +-
 hw/virtio/virtio-pci.c|   7 +-
 include/hw/i386/ioapic_internal.h |   1 +
 include/hw/i386/x86-iommu.h   |   1 +
 include/sysemu/kvm.h  |  25 ++--
 kvm-all.c |  10 +-
 kvm-stub.c|   5 +-
 target-i386/kvm.c |  15 ++-
 16 files changed, 386 insertions(+), 110 deletions(-)

-- 
2.1.4

[Qemu-devel] [V2 1/6] hw/msi: Allow platform devices to use explicit SID

[David Kiarie]

When using IOMMU platform devices like IOAPIC are required to make
interrupt remapping requests using explicit SID.We affiliate an MSI
route with a requester ID and a PCI device if present which ensures
that platform devices can call IOMMU interrupt remapping code with
explicit SID while maintaining compatility with the original code
which mainly dealt with PCI devices.

Signed-off-by: David Kiarie 
---
 hw/i386/intel_iommu.c |  3 +++
 hw/i386/kvm/pci-assign.c  | 12 
 hw/intc/ioapic.c  | 25 +
 hw/misc/ivshmem.c |  6 --
 hw/vfio/pci.c |  6 --
 hw/virtio/virtio-pci.c|  7 +--
 include/hw/i386/ioapic_internal.h |  1 +
 include/hw/i386/x86-iommu.h   |  1 +
 include/sysemu/kvm.h  | 25 ++---
 kvm-all.c | 10 ++
 kvm-stub.c|  5 +++--
 target-i386/kvm.c | 15 +--
 12 files changed, 79 insertions(+), 37 deletions(-)

diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index d6e02c8..496d836 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -2466,6 +2466,9 @@ static void vtd_realize(DeviceState *dev, Error **errp)
 vtd_init(s);
 sysbus_mmio_map(SYS_BUS_DEVICE(s), 0, Q35_HOST_BRIDGE_IOMMU_ADDR);
 pci_setup_iommu(bus, vtd_host_dma_iommu, dev);
+/* IOMMU expected IOAPIC SID */
+x86_iommu->ioapic_bdf = PCI_BUILD_BDF(Q35_PSEUDO_DEVFN_IOAPIC,
+Q35_PSEUDO_DEVFN_IOAPIC);
 /* Pseudo address space under root PCI bus. */
 pcms->ioapic_as = vtd_host_dma_iommu(bus, s, Q35_PSEUDO_DEVFN_IOAPIC);
 
diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
index 8238fbc..3f26be1 100644
--- a/hw/i386/kvm/pci-assign.c
+++ b/hw/i386/kvm/pci-assign.c
@@ -976,7 +976,8 @@ static void assigned_dev_update_msi(PCIDevice *pci_dev)
 if (ctrl_byte & PCI_MSI_FLAGS_ENABLE) {
 int virq;
 
-virq = kvm_irqchip_add_msi_route(kvm_state, 0, pci_dev);
+virq = kvm_irqchip_add_msi_route(kvm_state, 0, pci_dev,
+ pci_requester_id(pci_dev));
 if (virq < 0) {
 perror("assigned_dev_update_msi: kvm_irqchip_add_msi_route");
 return;
@@ -1014,7 +1015,8 @@ static void assigned_dev_update_msi_msg(PCIDevice 
*pci_dev)
 }
 
 kvm_irqchip_update_msi_route(kvm_state, assigned_dev->msi_virq[0],
- msi_get_message(pci_dev, 0), pci_dev);
+ msi_get_message(pci_dev, 0), pci_dev,
+ pci_requester_id(pci_dev));
 kvm_irqchip_commit_routes(kvm_state);
 }
 
@@ -1078,7 +1080,8 @@ static int assigned_dev_update_msix_mmio(PCIDevice 
*pci_dev)
 continue;
 }
 
-r = kvm_irqchip_add_msi_route(kvm_state, i, pci_dev);
+r = kvm_irqchip_add_msi_route(kvm_state, i, pci_dev,
+  pci_requester_id(pci_dev));
 if (r < 0) {
 return r;
 }
@@ -1599,7 +1602,8 @@ static void assigned_dev_msix_mmio_write(void *opaque, 
hwaddr addr,
 
 ret = kvm_irqchip_update_msi_route(kvm_state,
adev->msi_virq[i], msg,
-   pdev);
+   pdev,
+   pci_requester_id(pdev));
 if (ret) {
 error_report("Error updating irq routing entry (%d)", ret);
 }
diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
index 31791b0..b8b2f33 100644
--- a/hw/intc/ioapic.c
+++ b/hw/intc/ioapic.c
@@ -95,9 +95,17 @@ static void ioapic_entry_parse(uint64_t entry, struct 
ioapic_entry_info *info)
 (info->delivery_mode << MSI_DATA_DELIVERY_MODE_SHIFT);
 }
 
-static void ioapic_service(IOAPICCommonState *s)
+static void ioapic_as_write(IOAPICCommonState *s, uint32_t data, uint64_t addr)
 {
 AddressSpace *ioapic_as = PC_MACHINE(qdev_get_machine())->ioapic_as;
+MemTxAttrs attrs;
+
+attrs.requester_id = s->devid;
+address_space_stl_le(ioapic_as, addr, data, attrs, NULL);
+}
+
+static void ioapic_service(IOAPICCommonState *s)
+{
 struct ioapic_entry_info info;
 uint8_t i;
 uint32_t mask;
@@ -141,7 +149,7 @@ static void ioapic_service(IOAPICCommonState *s)
  * the IOAPIC message into a MSI one, and its
  * address space will decide whether we need a
  * translation. */
-stl_le_phys(ioapic_as, info.addr, info.data);
+ioapic_as_write(s, info.data, info.addr);
 }
 }
 }
@@ -197,7 +205,7 @@ static void ioapic_update_kvm_routes(IOAPICCommonState *s)
 ioapic_entry_parse(s->ioredtbl[i], );
 

[Qemu-devel] [V2 3/6] hw/iommu: Prepare for AMD IOMMU interrupt remapping

[David Kiarie]

Introduce macros and trace events for use in AMD IOMMU
interrupt remapping

Signed-off-by: David Kiarie 
---
 hw/i386/amd_iommu.h | 38 --
 1 file changed, 16 insertions(+), 22 deletions(-)

diff --git a/hw/i386/amd_iommu.h b/hw/i386/amd_iommu.h
index 2f4ac55..6f62e3a 100644
--- a/hw/i386/amd_iommu.h
+++ b/hw/i386/amd_iommu.h
@@ -187,11 +187,6 @@
 #define AMDVI_MT_LINT1  0xb
 #define AMDVI_MT_LINT0  0xe
 
-/* Ext reg, GA support */
-#define AMDVI_GASUP(1UL << 7)
-/* MMIO control GA enable bits */
-#define AMDVI_GAEN (1UL << 17)
-
 /* MSI interrupt type mask */
 #define AMDVI_IR_TYPE_MASK 0x300
 
@@ -204,12 +199,18 @@
 /* bits determining whether specific interrupts should be passed
  * split DTE into 64-bit chunks
  */
-#define AMDVI_DTE_INTPASS   56
-#define AMDVI_DTE_EINTPASS  57
-#define AMDVI_DTE_NMIPASS   58
-#define AMDVI_DTE_INTCTL60
-#define AMDVI_DTE_LINT0PASS 62
-#define AMDVI_DTE_LINT1PASS 63
+#define AMDVI_DTE_INTPASS_LSHIFT   56
+#define AMDVI_DTE_EINTPASS_LSHIFT  57
+#define AMDVI_DTE_NMIPASS_LSHIFT   58
+#define AMDVI_DTE_INTCTL_RSHIFT60
+#define AMDVI_DTE_LINT0PASS_LSHIFT 62
+#define AMDVI_DTE_LINT1PASS_LSHIFT 63
+
+/* INTCTL expected values */
+#define AMDVI_INTCTL_ABORT  0x0
+#define AMDVI_INTCTL_PASS   0x1
+#define AMDVI_INTCTL_REMAP  0x2
+#define AMDVI_INTCTL_RSVD   0x3
 
 /* interrupt data valid */
 #define AMDVI_IR_VALID  (1UL << 0)
@@ -220,17 +221,6 @@
 /* default IRTE size */
 #define AMDVI_DEFAULT_IRTE_SIZE 0x4
 
-/* IRTE size with GASup enabled */
-#define AMDVI_IRTE_SIZE_GASUP   0x10
-
-#define AMDVI_IRTE_VECTOR_MASK(0xffU << 16)
-#define AMDVI_IRTE_DEST_MASK  (0xffU << 8)
-#define AMDVI_IRTE_DM_MASK(0x1U << 6)
-#define AMDVI_IRTE_RQEOI_MASK (0x1U << 5)
-#define AMDVI_IRTE_INTTYPE_MASK   (0x7U << 2)
-#define AMDVI_IRTE_SUPIOPF_MASK   (0x1U << 1)
-#define AMDVI_IRTE_REMAP_MASK (0x1U << 0)
-
 #define AMDVI_IR_TABLE_SIZE_MASK 0xfe
 
 /* offsets into MSI data */
@@ -243,6 +233,10 @@
 #define AMDVI_MSI_ADDR_RH_RSHIFT   0x3
 #define AMDVI_MSI_ADDR_DEST_RSHIFT 0xc
 
+#define AMDVI_BUS_NUM  0x0
+/* AMD-Vi specific IOAPIC Device function */
+#define AMDVI_DEVFN_IOAPIC 0xa0
+
 #define AMDVI_LOCAL_APIC_ADDR 0xfee0
 
 /* extended feature support */
-- 
2.1.4

Re: [Qemu-devel] [PATCH v3 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support

[ashish mittal]

>> +/*
>> + * Convert the json formatted command line into qapi.
>> +*/
>> +
>> +static int vxhs_parse_json(BlockdevOptionsVxHS *conf,
>> +  QDict *options, Error **errp)
>> +{
...
>> +errno = EINVAL;
>> +return -errno;
>> +}
>
> Ewww this is really horrible code. It is open-coding a special purpose
> conversion of QemuOpts -> QDict -> QAPI scheme. We should really put
> my qdict_crumple() API impl as a pre-requisite of this, so you can then
> use qdict_crumple + qmp_input_visitor to do this conversion in a generic
> manner removing all this code.
>
>   https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg03118.html
>

Thanks for the suggestions. I will try to incorporate them in the next
version. Actually, I used block/gluster.c for reference (as advised).
This is exactly how it parses json CLI options. It also implements the
*parse_uri() in a similar way.


>> +/*
>> + * vxhs_parse_uri: Parse the incoming URI and populate *conf with the
>> + * vdisk_id, and all the host(s) information. Host at index 0 is local 
>> storage
>> + * agent and the rest, reflection target storage agents. The local storage
>> + * agent ip is the efficient internal address in the uri, e.g. 192.168.0.2.
>> + * The local storage agent address is stored at index 0. The reflection 
>> target
>> + * ips, are the E-W data network addresses of the reflection node agents, 
>> also
>> + * extracted from the uri.
>> + */
>> +static int vxhs_parse_uri(BlockdevOptionsVxHS *conf,
>> +   const char *filename)
>
> Delete this method entirely. We should not be adding URI syntax for any new
> block driver. The QAPI schema syntax is all we need.
>

Regards,
Ashish

Re: [Qemu-devel] [PATCH] softfloat: Fix warn about implicit conversion from int to int8_t

[Peter Maydell]

On 10 August 2016 at 20:00, Aurelien Jarno  wrote:
> On 2016-08-10 14:55, Pranith Kumar wrote:
>> Change the flag type to 'uint8_t' to fix the implicit conversion error.
>>
>> Signed-off-by: Pranith Kumar 


> Reviewed-by: Aurelien Jarno 

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH V1 1/1] arm64: Add an option to turn on/off host-backed vPMU support

[Peter Maydell]

On 13 August 2016 at 06:52, Wei Huang  wrote:
> This patch adds a pmu=[on/off] option to enable/disable host vPMU
> support in guest VM. There are several reasons to justify this option.
> First, host-backed vPMU can be problematic for cross-migration between
> different SoC as perf counters are architecture-dependent. It is more
> flexible to have an option to turn it on/off. Secondly this option
> matches the "pmu" option as supported in libvirt tool.
>
> Note that, like "has_el3", the "pmu" option is only made available on
> CPUs that support host-backed vPMU. They include:
> * cortex-a53 + kvm
> * cortex-a57 + kvm
> * host + kvm
> This option is removed in other configs where it doesn't make sense
> (e.g. cortex-a57 + TCG); and the default pmu support is off. This patch
> has been tested under both DT/ACPI modes.
>
> Signed-off-by: Wei Huang 
> ---
>  hw/arm/virt-acpi-build.c |  2 +-
>  hw/arm/virt.c|  2 +-
>  target-arm/cpu.c | 13 +
>  target-arm/cpu.h |  3 ++-
>  target-arm/cpu64.c   |  6 ++
>  target-arm/kvm64.c   | 10 +-
>  6 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 28fc59c..22fb9d9 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -540,7 +540,7 @@ build_madt(GArray *table_data, BIOSLinker *linker, 
> VirtGuestInfo *guest_info)
>  gicc->uid = i;
>  gicc->flags = cpu_to_le32(ACPI_GICC_ENABLED);
>
> -if (armcpu->has_pmu) {
> +if (armcpu->has_host_pmu) {
>  gicc->performance_interrupt = cpu_to_le32(PPI(VIRTUAL_PMU_IRQ));
>  }
>  }
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index a193b5a..4975f38 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -477,7 +477,7 @@ static void fdt_add_pmu_nodes(const VirtBoardInfo *vbi, 
> int gictype)
>
>  CPU_FOREACH(cpu) {
>  armcpu = ARM_CPU(cpu);
> -if (!armcpu->has_pmu ||
> +if (!armcpu->has_host_pmu ||
>  !kvm_arm_pmu_create(cpu, PPI(VIRTUAL_PMU_IRQ))) {
>  return;
>  }
> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
> index ce8b8f4..a527128 100644
> --- a/target-arm/cpu.c
> +++ b/target-arm/cpu.c
> @@ -509,6 +509,10 @@ static Property arm_cpu_rvbar_property =
>  static Property arm_cpu_has_el3_property =
>  DEFINE_PROP_BOOL("has_el3", ARMCPU, has_el3, true);
>
> +/* use property name "pmu" to match with other archs and libvirt */
> +static Property arm_cpu_has_host_pmu_property =
> +DEFINE_PROP_BOOL("pmu", ARMCPU, has_host_pmu, false);
> +
>  static Property arm_cpu_has_mpu_property =
>  DEFINE_PROP_BOOL("has-mpu", ARMCPU, has_mpu, true);
>
> @@ -552,6 +556,11 @@ static void arm_cpu_post_init(Object *obj)
>  #endif
>  }
>
> +if (arm_feature(>env, ARM_FEATURE_HOST_PMU)) {
> +qdev_property_add_static(DEVICE(obj), _cpu_has_host_pmu_property,
> + _abort);
> +}
> +
>  if (arm_feature(>env, ARM_FEATURE_MPU)) {
>  qdev_property_add_static(DEVICE(obj), _cpu_has_mpu_property,
>   _abort);
> @@ -648,6 +657,10 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
> **errp)
>  cpu->id_aa64pfr0 &= ~0xf000;
>  }
>
> +if (!cpu->has_host_pmu) {
> +unset_feature(env, ARM_FEATURE_HOST_PMU);
> +}
> +
>  if (!arm_feature(env, ARM_FEATURE_EL2)) {
>  /* Disable the hypervisor feature bits in the processor feature
>   * registers if we don't have EL2. These are id_pfr1[15:12] and
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 76d824d..f3f6d3f 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -580,7 +580,7 @@ struct ARMCPU {
>  /* CPU has security extension */
>  bool has_el3;
>  /* CPU has PMU (Performance Monitor Unit) */
> -bool has_pmu;
> +bool has_host_pmu;

Can you explain why you renamed this? "has_pmu" matches
the comment: it indicates that the emulated CPU has a PMU.
has_host_pmu would be something different (and would only
apply to KVM). It also looks weird in the code in the board
model: we should be saying "if the guest CPU has a PMU, wire
up its interrupt", not "if the host CPU has a PMU, wire
up a guest CPU interrupt".

>
>  /* CPU has memory protection unit */
>  bool has_mpu;
> @@ -1129,6 +1129,7 @@ enum arm_features {
>  ARM_FEATURE_V8_SHA256, /* implements SHA256 part of v8 Crypto Extensions 
> */
>  ARM_FEATURE_V8_PMULL, /* implements PMULL part of v8 Crypto Extensions */
>  ARM_FEATURE_THUMB_DSP, /* DSP insns supported in the Thumb encodings */
> +ARM_FEATURE_HOST_PMU, /* PMU supported by host */

ARM_FEATURE_ bits are for guest CPU features, not for
recording information about the host CPU.

>  };
>
>  static inline int arm_feature(CPUARMState *env, int feature)
> diff --git 

Re: [Qemu-devel] [PATCH V1 1/1] arm64: Add an option to turn on/off host-backed vPMU support

[Wei Huang]

On 8/15/16 04:31, Andrea Bolognani wrote:
> 
> On Sat, 2016-08-13 at 00:52 -0500, Wei Huang wrote:
>> This patch adds a pmu=[on/off] option to enable/disable host vPMU
>> support in guest VM. There are several reasons to justify this option.
>> First, host-backed vPMU can be problematic for cross-migration between
>> different SoC as perf counters are architecture-dependent. It is more
>> flexible to have an option to turn it on/off. Secondly this option
>> matches the "pmu" option as supported in libvirt tool.
>>  
>> Note that, like "has_el3", the "pmu" option is only made available on
>> CPUs that support host-backed vPMU. They include:
>>  * cortex-a53 + kvm
>>  * cortex-a57 + kvm
>>  * host + kvm
>> This option is removed in other configs where it doesn't make sense
>> (e.g. cortex-a57 + TCG); and the default pmu support is off. This patch
>> has been tested under both DT/ACPI modes.
>>  
>> Signed-off-by: Wei Huang 
>> ---
>>   hw/arm/virt-acpi-build.c |  2 +-
>>   hw/arm/virt.c|  2 +-
>>   target-arm/cpu.c | 13 +
>>   target-arm/cpu.h |  3 ++-
>>   target-arm/cpu64.c   |  6 ++
>>   target-arm/kvm64.c   | 10 +-
>>   6 files changed, 28 insertions(+), 8 deletions(-)
> 
> Did you already try driving this with libvirt? It should work
> out of the box.
> 
> If you haven't, I will do it :)

No, I haven't. All tests were done based on command line to QEMU. :-)

-Wei

> 
> -- 
> Andrea Bolognani / Red Hat / Virtualization
> 

Re: [Qemu-devel] [PATCH v2] hw/vfio/platform: Add Qualcomm Technologies, Inc HIDMA device support

[Peter Maydell]

Just cc'ing Eric on his new email address...

thanks
-- PMM

On 14 August 2016 at 16:42, Shanker Donthineni  wrote:
> This patch introduces the Qualcomm Technologies, Inc HIDMA device and
> allows passthrough the host HIDMA device to a guest machine using the
> vfio-platform framework.
>
> A platform device tree node is created for the guest machine which
> contains the compat string 'qcom,hidma-1.0', mmio regions, active high
> SPIs, and an optional property dma-coherent.
>
> Signed-off-by: Vikram Sethi 
> Signed-off-by: Shanker Donthineni 
> ---
> Changes sicnce v1:
>   combined patches [v1 1/2] and [v1 2/2].
>   added '#include "qemu/osdep.h'.
>   changed compact string to 'qcom,hidma-1.0' to match the host driver.
>   set dma-coherent property based on the IOMMU coherency status.
>
>  hw/arm/sysbus-fdt.c   | 67 
> +++
>  hw/vfio/Makefile.objs |  1 +
>  hw/vfio/qcom-hidma.c  | 58 +
>  include/hw/vfio/vfio-qcom-hidma.h | 50 +
>  4 files changed, 176 insertions(+)
>  create mode 100644 hw/vfio/qcom-hidma.c
>  create mode 100644 include/hw/vfio/vfio-qcom-hidma.h
>
> diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
> index 5debb33..bdf8cbb 100644
> --- a/hw/arm/sysbus-fdt.c
> +++ b/hw/arm/sysbus-fdt.c
> @@ -27,6 +27,7 @@
>  #include "qemu-common.h"
>  #ifdef CONFIG_LINUX
>  #include 
> +#include 
>  #endif
>  #include "hw/arm/sysbus-fdt.h"
>  #include "qemu/error-report.h"
> @@ -36,6 +37,7 @@
>  #include "hw/vfio/vfio-platform.h"
>  #include "hw/vfio/vfio-calxeda-xgmac.h"
>  #include "hw/vfio/vfio-amd-xgbe.h"
> +#include "hw/vfio/vfio-qcom-hidma.h"
>  #include "hw/arm/fdt.h"
>
>  /*
> @@ -262,6 +264,70 @@ static int 
> add_calxeda_midway_xgmac_fdt_node(SysBusDevice *sbdev, void *opaque)
>  return 0;
>  }
>
> +/**
> + * add_qcom_hidma_fdt_node
> + *
> + * Generates a simple node with following properties:
> + * compatible string, regs, active-high interrupts, and optional dma-coherent
> + */
> +static int add_qcom_hidma_fdt_node(SysBusDevice *sbdev, void *opaque)
> +{
> +VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
> +struct VFIOGroup *group = vdev->vbasedev.group;
> +VFIODevice *vbasedev = >vbasedev;
> +PlatformBusFDTData *data = opaque;
> +const char *parent_node = data->pbus_node_name;
> +PlatformBusDevice *pbus = data->pbus;
> +uint32_t *irq_attr, *reg_attr;
> +uint64_t mmio_base, irq_number;
> +void *fdt = data->fdt;
> +int compat_str_len, i, ret;
> +char *nodename;
> +
> +mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, 0);
> +nodename = g_strdup_printf("%s/%s@%" PRIx64, parent_node,
> +   vbasedev->name, mmio_base);
> +assert(nodename);
> +qemu_fdt_add_subnode(fdt, nodename);
> +
> +compat_str_len = strlen(vdev->compat) + 1;
> +qemu_fdt_setprop(fdt, nodename, "compatible",
> +  vdev->compat, compat_str_len);
> +
> +/* Check if the DMA cache coherency was enabled in IOMMU */
> +ret = ioctl(group->container->fd, VFIO_CHECK_EXTENSION, 
> VFIO_DMA_CC_IOMMU);
> +if (ret > 0) {
> +qemu_fdt_setprop(fdt, nodename, "dma-coherent", "", 0);
> +}
> +
> +reg_attr = g_new(uint32_t, vbasedev->num_regions * 2);
> +assert(reg_attr);
> +for (i = 0; i < vbasedev->num_regions; i++) {
> +mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, i);
> +reg_attr[2 * i] = cpu_to_be32(mmio_base);
> +reg_attr[2 * i + 1] = cpu_to_be32(
> +memory_region_size(vdev->regions[i]->mem));
> +}
> +qemu_fdt_setprop(fdt, nodename, "reg", reg_attr,
> + vbasedev->num_regions * 2 * sizeof(uint32_t));
> +
> +irq_attr = g_new(uint32_t, vbasedev->num_irqs * 3);
> +assert(irq_attr);
> +for (i = 0; i < vbasedev->num_irqs; i++) {
> +irq_number = platform_bus_get_irqn(pbus, sbdev , i)
> + + data->irq_start;
> +irq_attr[3 * i] = cpu_to_be32(GIC_FDT_IRQ_TYPE_SPI);
> +irq_attr[3 * i + 1] = cpu_to_be32(irq_number);
> +irq_attr[3 * i + 2] = cpu_to_be32(GIC_FDT_IRQ_FLAGS_LEVEL_HI);
> +}
> +qemu_fdt_setprop(fdt, nodename, "interrupts",
> + irq_attr, vbasedev->num_irqs * 3 * sizeof(uint32_t));
> +g_free(irq_attr);
> +g_free(reg_attr);
> +g_free(nodename);
> +return 0;
> +}
> +
>  /* AMD xgbe properties whose values are copied/pasted from host */
>  static HostProperty amd_xgbe_copied_properties[] = {
>  {"compatible", false},
> @@ -420,6 +486,7 @@ static const NodeCreationPair add_fdt_node_functions[] = {
>  #ifdef CONFIG_LINUX
>  {TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node},
>  {TYPE_VFIO_AMD_XGBE, add_amd_xgbe_fdt_node},
> +{TYPE_VFIO_QCOM_HIDMA, 

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

[Alex Williamson]

On Mon, 15 Aug 2016 09:38:52 +
"Tian, Kevin"  wrote:

> > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > Sent: Saturday, August 13, 2016 8:37 AM
> > 
> > 
> > 
> > On 8/13/2016 2:46 AM, Alex Williamson wrote:  
> > > On Sat, 13 Aug 2016 00:14:39 +0530
> > > Kirti Wankhede  wrote:
> > >  
> > >> On 8/10/2016 12:30 AM, Alex Williamson wrote:  
> > >>> On Thu, 4 Aug 2016 00:33:51 +0530
> > >>> Kirti Wankhede  wrote:
> > >>>
> > >>> This is used later by mdev_device_start() and mdev_device_stop() to get
> > >>> the parent_device so it can call the start and stop ops callbacks
> > >>> respectively.  That seems to imply that all of instances for a given
> > >>> uuid come from the same parent_device.  Where is that enforced?  I'm
> > >>> still having a hard time buying into the uuid+instance plan when it
> > >>> seems like each mdev_device should have an actual unique uuid.
> > >>> Userspace tools can figure out which uuids to start for a given user, I
> > >>> don't see much value in collecting them to instances within a uuid.
> > >>>  
> > >>
> > >> Initially we started discussion with VM_UUID+instance suggestion, where
> > >> instance was introduced to support multiple devices in a VM.  
> > >
> > > The instance number was never required in order to support multiple
> > > devices in a VM, IIRC this UUID+instance scheme was to appease NVIDIA
> > > management tools which wanted to re-use the VM UUID by creating vGPU
> > > devices with that same UUID and therefore associate udev events to a
> > > given VM.  Only then does an instance number become necessary since the
> > > UUID needs to be static for a vGPUs within a VM.  This has always felt
> > > like a very dodgy solution when we should probably just be querying
> > > libvirt to give us a device to VM association.  
> 
> Agree with Alex here. We'd better not assume that UUID will be a VM_UUID
> for mdev in the basic design. It's bound to NVIDIA management stack too 
> tightly.
> 
> I'm OK to give enough flexibility for various upper level management stacks,
> e.g. instead of $UUID+INDEX style, would $UUID+STRING provide a better
> option where either UUID or STRING could be optional? Upper management 
> stack can choose its own policy to identify a mdev:
> 
> a) $UUID only, so each mdev is allocated with a unique UUID
> b) STRING only, which could be an index (0, 1, 2, ...), or any combination 
> (vgpu0, vgpu1, etc.)
> c) $UUID+STRING, where UUID could be a VM UUID, and STRING could be
> a numeric index
> 
> > >  
> > >> 'mdev_create' creates device and 'mdev_start' is to commit resources of
> > >> all instances of similar devices assigned to VM.
> > >>
> > >> For example, to create 2 devices:
> > >> # echo "$UUID:0:params" > /sys/devices/../mdev_create
> > >> # echo "$UUID:1:params" > /sys/devices/../mdev_create
> > >>
> > >> "$UUID-0" and "$UUID-1" devices are created.
> > >>
> > >> Commit resources for above devices with single 'mdev_start':
> > >> # echo "$UUID" > /sys/class/mdev/mdev_start
> > >>
> > >> Considering $UUID to be a unique UUID of a device, we don't need
> > >> 'instance', so 'mdev_create' would look like:
> > >>
> > >> # echo "$UUID1:params" > /sys/devices/../mdev_create
> > >> # echo "$UUID2:params" > /sys/devices/../mdev_create
> > >>
> > >> where $UUID1 and $UUID2 would be mdev device's unique UUID and 'params'
> > >> would be vendor specific parameters.
> > >>
> > >> Device nodes would be created as "$UUID1" and "$UUID"
> > >>
> > >> Then 'mdev_start' would be:
> > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_start
> > >>
> > >> Similarly 'mdev_stop' and 'mdev_destroy' would be:
> > >>
> > >> # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_stop  
> > >
> > > I'm not sure a comma separated list makes sense here, for both
> > > simplicity in the kernel and more fine grained error reporting, we
> > > probably want to start/stop them individually.  Actually, why is it
> > > that we can't use the mediated device being opened and released to
> > > automatically signal to the backend vendor driver to commit and release
> > > resources? I don't fully understand why userspace needs this interface.  
> 
> There is a meaningful use of start/stop interface, as required in live
> migration support. Such interface allows vendor driver to quiescent 
> mdev activity on source device before mdev hardware state is snapshot,
> and then resume mdev activity on dest device after its state is recovered.
> Intel has implemented experimental live migration support in KVMGT (soon
> to release), based on above two interfaces (plus another two to get/set
> mdev state).

Ok, that's actually an interesting use case for start/stop.

> > 
> > For NVIDIA vGPU solution we need to know all devices assigned to a VM in
> > one shot to commit resources of all vGPUs assigned to a VM along with
> > some common resources.  
> 
> Kirti, can you elaborate the background about above one-shot commit

Re: [Qemu-devel] MTTCG status updates, benchmark results and KVM forum plans

[Emilio G. Cota]

On Mon, Aug 15, 2016 at 11:46:32 +0100, Alex Bennée wrote:
> As far as I'm aware the following work is still ongoing:
> 
> Emilo: cmpxchg atomics
> Alvise: LL/SC modelling

I've been tinkering with an experimental patch to do proper LL/SC. The idea
is to rely on hardware transactional memory, so that stores don't have
to be tracked. The trickiest thing is the fallback path, for which I'm
trying to (ab)use EXCP_ATOMIC to execute exclusively from the ldrex
all the way to the strex.

To test it, I'm using aarch64-linux-user running qht-bench compiled on
an aarch64 machine. I'm running on an Intel Skylake host (Skylake has
no known TSX bugs)

However, I'm finding issues that might not have to do with the
patch itself.

- On the latest MTTCG+cmpxchg tree (45c11751ed7 a.k.a.
  bennee/mttcg/base-patches-v4-with-cmpxchg-atomics-v2), QEMU loops
  forever without making progress in the instruction stream, even
  with taskset -c 0.
- On the cmpxchg tree (rth's atomic-2 branch [1]), it works more
  reliably, although tb_lock is held around tb_find_fast so parallelism isn't
  very high. Still, it sometimes triggers the assert below.
  - Applying the "remove tb_lock around hot path" patch makes it
easier to trigger this assert in cpu-exec.c:650 (approx.):
/* Assert that the compiler does not smash local variables. */
g_assert(cpu == current_cpu)
I've also seen triggered the assert immediately after that one, as well
as the rcu_read_unlock depth assert.
  The asserts are usually triggered when all threads exit (by returning
  NULL) at roughly the same time.
  However, they cannot be triggered with taskset -c 0, which makes me
  suspect that somehow start_exclusive isn't working as intended.

Any tips would be appreciated! I'll reply with a patch that uses RTM,
the one below is fallback path all the way, and the best to reproduce
the above.

Thanks,

Emilio

[1] https://github.com/rth7680/qemu/commits/atomic-2

>From ed6af6eb364e5a36e81d7cc8143c0e9783c50587 Mon Sep 17 00:00:00 2001
From: "Emilio G. Cota" 
Date: Mon, 15 Aug 2016 00:27:42 +0200
Subject: [PATCH] aarch64: use TSX for ldrex/strex (fallback path only)

Signed-off-by: Emilio G. Cota 
---
 linux-user/main.c  |  5 +++--
 target-arm/helper-a64.c| 23 +++
 target-arm/helper-a64.h|  4 
 target-arm/translate-a64.c | 15 +--
 4 files changed, 39 insertions(+), 8 deletions(-)

diff --git a/linux-user/main.c b/linux-user/main.c
index 9880505..6922faa 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -192,8 +192,9 @@ static void step_atomic(CPUState *cpu)
 
 /* Since we got here, we know that parallel_cpus must be true.  */
 parallel_cpus = false;
-cpu_exec_step(cpu);
-parallel_cpus = true;
+while (!parallel_cpus) {
+cpu_exec_step(cpu);
+}
 
 end_exclusive();
 }
diff --git a/target-arm/helper-a64.c b/target-arm/helper-a64.c
index 8ce518b..a97b631 100644
--- a/target-arm/helper-a64.c
+++ b/target-arm/helper-a64.c
@@ -579,3 +579,26 @@ uint64_t HELPER(paired_cmpxchg64_be)(CPUARMState *env, 
uint64_t addr,
 
 return !success;
 }
+
+void HELPER(xbegin)(CPUARMState *env)
+{
+uintptr_t ra = GETPC();
+
+if (parallel_cpus) {
+cpu_loop_exit_atomic(ENV_GET_CPU(env), ra);
+}
+}
+
+void HELPER(xend)(void)
+{
+assert(!parallel_cpus);
+parallel_cpus = true;
+}
+
+uint64_t HELPER(x_ok)(void)
+{
+if (!parallel_cpus) {
+return 1;
+}
+return 0;
+}
diff --git a/target-arm/helper-a64.h b/target-arm/helper-a64.h
index dd32000..e7ede43 100644
--- a/target-arm/helper-a64.h
+++ b/target-arm/helper-a64.h
@@ -48,3 +48,7 @@ DEF_HELPER_FLAGS_3(crc32_64, TCG_CALL_NO_RWG_SE, i64, i64, 
i64, i32)
 DEF_HELPER_FLAGS_3(crc32c_64, TCG_CALL_NO_RWG_SE, i64, i64, i64, i32)
 DEF_HELPER_FLAGS_4(paired_cmpxchg64_le, TCG_CALL_NO_WG, i64, env, i64, i64, 
i64)
 DEF_HELPER_FLAGS_4(paired_cmpxchg64_be, TCG_CALL_NO_WG, i64, env, i64, i64, 
i64)
+
+DEF_HELPER_1(xbegin, void, env)
+DEF_HELPER_0(x_ok, i64)
+DEF_HELPER_0(xend, void)
diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
index 450c359..cfcf440 100644
--- a/target-arm/translate-a64.c
+++ b/target-arm/translate-a64.c
@@ -1760,6 +1760,8 @@ static void gen_load_exclusive(DisasContext *s, int rt, 
int rt2,
 TCGv_i64 tmp = tcg_temp_new_i64();
 TCGMemOp be = s->be_data;
 
+gen_helper_xbegin(cpu_env);
+
 g_assert(size <= 3);
 if (is_pair) {
 TCGv_i64 hitmp = tcg_temp_new_i64();
@@ -1825,6 +1827,9 @@ static void gen_store_exclusive(DisasContext *s, int rd, 
int rt, int rt2,
 tcg_gen_brcond_i64(TCG_COND_NE, addr, cpu_exclusive_addr, fail_label);
 
 tmp = tcg_temp_new_i64();
+gen_helper_x_ok(tmp);
+tcg_gen_brcondi_i64(TCG_COND_EQ, tmp, 0, fail_label);
+
 if (is_pair) {
 if (size == 2) {
 TCGv_i64 val = tcg_temp_new_i64();
@@ -1844,16 +1849,14 @@ static void 

Re: [Qemu-devel] [PATCH v14 1/9] target-avr: AVR cores support is added.

[Michael Rolnik]

I definitely fixed ask your comments from previous review. But as it seems
I have done a terrible mistake sending wrong patches. Sorry.

On Mon, Aug 15, 2016, 6:46 PM Peter Maydell 
wrote:

> On 15 August 2016 at 16:31, Michael Rolnik  wrote:
> > I remember I did it. So it seems to be a wrong review.
>
> Well, it's definitely still in the wrong place in the v14
> patchset you sent out: http://patchwork.ozlabs.org/patch/654143/
> Did you send out the wrong patchset by mistake?
>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH v14 1/9] target-avr: AVR cores support is added.

[Peter Maydell]

On 15 August 2016 at 16:31, Michael Rolnik  wrote:
> I remember I did it. So it seems to be a wrong review.

Well, it's definitely still in the wrong place in the v14
patchset you sent out: http://patchwork.ozlabs.org/patch/654143/
Did you send out the wrong patchset by mistake?

thanks
-- PMM

[Qemu-devel] [PATCH] aarch64: use TSX for ldrex/strex

[Emilio G. Cota]

Configure with --extra-cflags="-mrtm"

Signed-off-by: Emilio G. Cota 
---
 linux-user/main.c  |  5 +++--
 target-arm/helper-a64.c| 42 ++
 target-arm/helper-a64.h|  4 
 target-arm/translate-a64.c | 15 +--
 4 files changed, 58 insertions(+), 8 deletions(-)

diff --git a/linux-user/main.c b/linux-user/main.c
index 9880505..6922faa 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -192,8 +192,9 @@ static void step_atomic(CPUState *cpu)
 
 /* Since we got here, we know that parallel_cpus must be true.  */
 parallel_cpus = false;
-cpu_exec_step(cpu);
-parallel_cpus = true;
+while (!parallel_cpus) {
+cpu_exec_step(cpu);
+}
 
 end_exclusive();
 }
diff --git a/target-arm/helper-a64.c b/target-arm/helper-a64.c
index 8ce518b..af45694 100644
--- a/target-arm/helper-a64.c
+++ b/target-arm/helper-a64.c
@@ -33,6 +33,8 @@
 #include "tcg.h"
 #include  /* For crc32 */
 
+#include 
+
 /* C2.4.7 Multiply and divide */
 /* special cases for 0 and LLONG_MIN are mandated by the standard */
 uint64_t HELPER(udiv64)(uint64_t num, uint64_t den)
@@ -579,3 +581,43 @@ uint64_t HELPER(paired_cmpxchg64_be)(CPUARMState *env, 
uint64_t addr,
 
 return !success;
 }
+
+void HELPER(xbegin)(CPUARMState *env)
+{
+uintptr_t ra = GETPC();
+int status;
+int retries = 100;
+
+ retry:
+status = _xbegin();
+if (status != _XBEGIN_STARTED) {
+if (status && retries) {
+retries--;
+goto retry;
+}
+if (parallel_cpus) {
+cpu_loop_exit_atomic(ENV_GET_CPU(env), ra);
+}
+}
+}
+
+void HELPER(xend)(void)
+{
+if (_xtest()) {
+_xend();
+} else {
+assert(!parallel_cpus);
+parallel_cpus = true;
+}
+}
+
+uint64_t HELPER(x_ok)(void)
+{
+if (_xtest()) {
+return 1;
+}
+if (!parallel_cpus) {
+return 1;
+}
+return 0;
+}
diff --git a/target-arm/helper-a64.h b/target-arm/helper-a64.h
index dd32000..e7ede43 100644
--- a/target-arm/helper-a64.h
+++ b/target-arm/helper-a64.h
@@ -48,3 +48,7 @@ DEF_HELPER_FLAGS_3(crc32_64, TCG_CALL_NO_RWG_SE, i64, i64, 
i64, i32)
 DEF_HELPER_FLAGS_3(crc32c_64, TCG_CALL_NO_RWG_SE, i64, i64, i64, i32)
 DEF_HELPER_FLAGS_4(paired_cmpxchg64_le, TCG_CALL_NO_WG, i64, env, i64, i64, 
i64)
 DEF_HELPER_FLAGS_4(paired_cmpxchg64_be, TCG_CALL_NO_WG, i64, env, i64, i64, 
i64)
+
+DEF_HELPER_1(xbegin, void, env)
+DEF_HELPER_0(x_ok, i64)
+DEF_HELPER_0(xend, void)
diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
index 450c359..cfcf440 100644
--- a/target-arm/translate-a64.c
+++ b/target-arm/translate-a64.c
@@ -1760,6 +1760,8 @@ static void gen_load_exclusive(DisasContext *s, int rt, 
int rt2,
 TCGv_i64 tmp = tcg_temp_new_i64();
 TCGMemOp be = s->be_data;
 
+gen_helper_xbegin(cpu_env);
+
 g_assert(size <= 3);
 if (is_pair) {
 TCGv_i64 hitmp = tcg_temp_new_i64();
@@ -1825,6 +1827,9 @@ static void gen_store_exclusive(DisasContext *s, int rd, 
int rt, int rt2,
 tcg_gen_brcond_i64(TCG_COND_NE, addr, cpu_exclusive_addr, fail_label);
 
 tmp = tcg_temp_new_i64();
+gen_helper_x_ok(tmp);
+tcg_gen_brcondi_i64(TCG_COND_EQ, tmp, 0, fail_label);
+
 if (is_pair) {
 if (size == 2) {
 TCGv_i64 val = tcg_temp_new_i64();
@@ -1844,16 +1849,14 @@ static void gen_store_exclusive(DisasContext *s, int 
rd, int rt, int rt2,
 }
 } else {
 TCGv_i64 val = cpu_reg(s, rt);
-tcg_gen_atomic_cmpxchg_i64(tmp, addr, cpu_exclusive_val, val,
-   get_mem_index(s),
-   size | MO_ALIGN | s->be_data);
-tcg_gen_setcond_i64(TCG_COND_NE, tmp, tmp, cpu_exclusive_val);
+tcg_gen_qemu_st_i64(val, addr, get_mem_index(s), s->be_data + size);
 }
 
 tcg_temp_free_i64(addr);
-
-tcg_gen_mov_i64(cpu_reg(s, rd), tmp);
 tcg_temp_free_i64(tmp);
+
+tcg_gen_movi_i64(cpu_reg(s, rd), 0);
+gen_helper_xend();
 tcg_gen_br(done_label);
 
 gen_set_label(fail_label);
-- 
2.7.4

Re: [Qemu-devel] [PATCH v14 9/9] target-avr: adding instruction decoder

[Peter Maydell]

On 29 July 2016 at 16:32, Michael Rolnik  wrote:
> Signed-off-by: Michael Rolnik 
> ---
>  target-avr/Makefile.objs  |1 +
>  target-avr/cpugen/src/.cpugen.cpp.swp |  Bin 0 -> 24576 bytes

What is this binary ? It looks from the filename like some
editor backup file -- is it supposed to be here?

>  target-avr/decode.c   |  693 +++
>  target-avr/helper.c   |2 +
>  target-avr/helper.h   |1 +
>  target-avr/translate-inst.c   | 1529 
> +
>  target-avr/translate.c|   29 +-
>  7 files changed, 1473 insertions(+), 782 deletions(-)
>  create mode 100644 target-avr/cpugen/src/.cpugen.cpp.swp
>  create mode 100644 target-avr/decode.c

> diff --git a/target-avr/helper.c b/target-avr/helper.c
> index 9635d38..bbb725e 100644
> --- a/target-avr/helper.c
> +++ b/target-avr/helper.c
> @@ -153,6 +153,7 @@ void tlb_fill(CPUState *cs, target_ulong vaddr, 
> MMUAccessType access_type,
>
>  tlb_set_page_with_attrs(cs, vaddr, paddr, attrs, prot, mmu_idx, 
> page_size);
>  }
> +
>  void helper_sleep(CPUAVRState *env)
>  {
>  CPUState *cs = CPU(avr_env_get_cpu(env));
> @@ -160,6 +161,7 @@ void helper_sleep(CPUAVRState *env)
>  cs->exception_index = EXCP_HLT;
>  cpu_loop_exit(cs);
>  }
> +
>  void helper_unsupported(CPUAVRState *env)
>  {
>  CPUState *cs = CPU(avr_env_get_cpu(env));
> diff --git a/target-avr/helper.h b/target-avr/helper.h
> index 6036315..a533d2a 100644
> --- a/target-avr/helper.h
> +++ b/target-avr/helper.h
> @@ -26,3 +26,4 @@ DEF_HELPER_3(outb, void, env, i32, i32)
>  DEF_HELPER_2(inb, tl, env, i32)
>  DEF_HELPER_3(fullwr, void, env, i32, i32)
>  DEF_HELPER_2(fullrd, tl, env, i32)
> +
> diff --git a/target-avr/translate-inst.c b/target-avr/translate-inst.c
> index d1dce42..3afb0d8 100644
> --- a/target-avr/translate-inst.c
> +++ b/target-avr/translate-inst.c
> @@ -28,14 +28,14 @@ static void gen_add_CHf(TCGv R, TCGv Rd, TCGv Rr)
>  TCGv t2 = tcg_temp_new_i32();
>  TCGv t3 = tcg_temp_new_i32();
>
> -tcg_gen_and_tl(t1, Rd, Rr); /*  t1 = Rd & Rr  */
> -tcg_gen_andc_tl(t2, Rd, R); /*  t2 = Rd & ~R  */
> -tcg_gen_andc_tl(t3, Rr, R); /*  t3 = Rr & ~R  */
> -tcg_gen_or_tl(t1, t1, t2);  /*  t1 = t1 | t2 | t3  */
> +tcg_gen_and_tl(t1, Rd, Rr); /* t1 = Rd & Rr */
> +tcg_gen_andc_tl(t2, Rd, R); /* t2 = Rd & ~R */
> +tcg_gen_andc_tl(t3, Rr, R); /* t3 = Rr & ~R */
> +tcg_gen_or_tl(t1, t1, t2); /* t1 = t1 | t2 | t3 */

Please don't add code in one patch and then change its spacing in a
later patch. Pretty much all of this patch looks like changes that
should have been squashed into preceding patches.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v14 0/9] 8bit AVR cores

[Peter Maydell]

On 29 July 2016 at 16:32, Michael Rolnik  wrote:
> This series of patches adds 8bit AVR cores to QEMU.
> All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully tested 
> yet.
> However I was able to execute simple code with functions. e.g fibonacci 
> calculation.
> This series of patches include a non real, sample board.
> No fuses support yet. PC is set to 0 at reset.

Hi; I have reviewed patches 1-3 (the structure of the CPU and
the board) and 9 (which looks like a patch that shouldn't exist).
I'm leaving 4-8 (the actual instruction emulation) for rth to
review.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v14 3/9] target-avr: adding a sample AVR board

[Peter Maydell]

On 29 July 2016 at 16:32, Michael Rolnik  wrote:
> Signed-off-by: Michael Rolnik 
> ---
>  MAINTAINERS  |   6 +++
>  hw/avr/Makefile.objs |  21 +
>  hw/avr/sample.c  | 117 
> +++
>  3 files changed, 144 insertions(+)
>  create mode 100644 hw/avr/Makefile.objs
>  create mode 100644 hw/avr/sample.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d1439a8..1435040 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -110,6 +110,12 @@ F: disas/arm.c
>  F: disas/arm-a64.cc
>  F: disas/libvixl/
>
> +AVR
> +M: Michael Rolnik 
> +S: Maintained
> +F: target-avr/
> +F: hw/avr/
> +
>  CRIS
>  M: Edgar E. Iglesias 
>  S: Maintained
> diff --git a/hw/avr/Makefile.objs b/hw/avr/Makefile.objs
> new file mode 100644
> index 000..8f537c9
> --- /dev/null
> +++ b/hw/avr/Makefile.objs
> @@ -0,0 +1,21 @@
> +#
> +#  QEMU AVR CPU
> +#
> +#  Copyright (c) 2016 Michael Rolnik
> +#
> +#  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.1 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
> +#  
> +#
> +
> +obj-y += sample.o
> diff --git a/hw/avr/sample.c b/hw/avr/sample.c
> new file mode 100644
> index 000..2c1cd84
> --- /dev/null
> +++ b/hw/avr/sample.c
> @@ -0,0 +1,117 @@
> +/*
> + * QEMU AVR CPU
> + *
> + * Copyright (c) 2016 Michael Rolnik
> + *
> + * 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.1 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
> + * 
> + */
> +
> +/*
> + *  NOTE:
> + *  This is not a real AVR board !!! This is an example !!!
> + *
> + *This example can be used to build a real AVR board.
> + *
> + *  This example board loads provided binary file into flash memory and
> + *  executes it from 0x address in the code memory space.
> + *
> + *  This example does not implement/install any AVR specific on board
> + *  devices except SampleIO device which is an example as well.

You forgot to update this comment when you removed the SampleIO device.

> + *
> + *  Currently used for AVR CPU validation
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "qemu-common.h"
> +#include "cpu.h"
> +#include "hw/hw.h"
> +#include "sysemu/sysemu.h"
> +#include "sysemu/qtest.h"
> +#include "ui/console.h"
> +#include "hw/boards.h"
> +#include "hw/devices.h"
> +#include "hw/loader.h"
> +#include "qemu/error-report.h"
> +#include "exec/address-spaces.h"
> +#include "include/hw/sysbus.h"
> +
> +#define VIRT_BASE_FLASH 0x
> +#define VIRT_BASE_ISRAM 0x0100
> +#define VIRT_BASE_EXMEM 0x1100
> +#define VIRT_BASE_EEPROM 0x
> +
> +#define SIZE_FLASH 0x0002
> +#define SIZE_ISRAM 0x1000
> +#define SIZE_EXMEM 0x0001
> +#define SIZE_EEPROM 0x1000
> +#define SIZE_IOREG SIZE_REGS
> +
> +#define PHYS_BASE_FLASH (PHYS_BASE_CODE)
> +
> +#define PHYS_BASE_ISRAM (PHYS_BASE_DATA)
> +#define PHYS_BASE_EXMEM (PHYS_BASE_ISRAM + SIZE_ISRAM)
> +#define PHYS_BASE_EEPROM (PHYS_BASE_EXMEM + SIZE_EXMEM)
> +
> +#define PHYS_BASE_IOREG (PHYS_BASE_REGS + 0x20)
> +
> +static void sample_init(MachineState *machine)
> +{
> +MemoryRegion *address_space_mem = get_system_memory();
> +
> +MemoryRegion *ram;
> +MemoryRegion *flash;
> +unsigned ram_size = SIZE_ISRAM + SIZE_EXMEM;
> +
> +AVRCPU *cpu_avr ATTRIBUTE_UNUSED;
> +
> +ram = g_new(MemoryRegion, 1);
> +flash = g_new(MemoryRegion, 1);
> +
> +cpu_avr = cpu_avr_init("avr5");
> +
> +memory_region_allocate_system_memory(ram, NULL, "avr.ram", ram_size);
> +memory_region_add_subregion(address_space_mem, PHYS_BASE_ISRAM, ram);
> +
> +memory_region_init_rom(flash, NULL, "avr.flash", SIZE_FLASH, 
> _fatal);
> +

Re: [Qemu-devel] [PATCH v14 1/9] target-avr: AVR cores support is added.

[Michael Rolnik]

I remember I did it. So it seems to be a wrong review.

On Mon, Aug 15, 2016, 6:28 PM Peter Maydell 
wrote:

> On 29 July 2016 at 16:32, Michael Rolnik  wrote:
> > 1. basic CPU structure
> > 2. registers
> > 3. no instructions
> > 4. saving sreg, rampD, rampX, rampY, rampD, eind in HW representation
> >
> > Signed-off-by: Michael Rolnik 
>
> > diff --git a/configure b/configure
> > index f57fcc6..c4d58b4 100755
> > --- a/configure
> > +++ b/configure
> > @@ -5641,6 +5641,8 @@ case "$target_name" in
> >x86_64)
> >  TARGET_BASE_ARCH=i386
> >;;
> > +  avr)
> > +  ;;
>
> I asked you to move this in my review of v12, but you haven't.
>
> >alpha)
> >;;
> >arm|armeb)
> > @@ -5837,6 +5839,9 @@ disas_config() {
> >
> >  for i in $ARCH $TARGET_BASE_ARCH ; do
> >case "$i" in
> > +  avr)
> > +disas_config "AVR"
> > +  ;;
>
> Ditto.
>
> >alpha)
> >  disas_config "ALPHA"
> >;;
>
> > +#ifndef QEMU_AVR_CPU_QOM_H
> > +#define QEMU_AVR_CPU_QOM_H
> > +
> > +#include "qom/cpu.h"
> > +
> > +#define TYPE_AVR_CPU "avr"
> > +
> > +#define AVR_CPU_CLASS(klass) \
> > +OBJECT_CLASS_CHECK(AVRCPUClass, (klass),
> TYPE_AVR_CPU)
> > +#define AVR_CPU(obj) \
> > +OBJECT_CHECK(AVRCPU, (obj), TYPE_AVR_CPU)
> > +#define AVR_CPU_GET_CLASS(obj) \
> > +OBJECT_GET_CLASS(AVRCPUClass, (obj), TYPE_AVR_CPU)
> > +
> > +/**
> > +*  AVRCPUClass:
> > +*  @parent_realize: The parent class' realize handler.
> > +*  @parent_reset: The parent class' reset handler.
> > +*  @vr: Version Register value.
> > +*
> > +*  A AVR CPU model.
> > + */
>
> The spacing here is still wrong.
>
> > +typedef struct AVRCPUClass {
> > +CPUClass parent_class;
> > +
> > +DeviceRealize parent_realize;
> > +void (*parent_reset)(CPUState *cpu);
> > +} AVRCPUClass;
> > +
> > +/**
> > +*  AVRCPU:
> > +*  @env: #CPUAVRState
> > +*
> > +*  A AVR CPU.
> > +*/
>
> Ditto.
>
> > +typedef struct AVRCPU {
> > +/* < private > */
> > +CPUState parent_obj;
> > +/* < public > */
> > +
> > +CPUAVRState env;
> > +} AVRCPU;
>
> > +static bool avr_cpu_has_work(CPUState *cs)
> > +{
> > +AVRCPU *cpu = AVR_CPU(cs);
> > +CPUAVRState *env = >env;
> > +
> > +return (cs->interrupt_request
> > +&   (CPU_INTERRUPT_HARD
> > +| CPU_INTERRUPT_RESET))
> > +&&  cpu_interrupts_enabled(env);
>
> I asked you to fix this spacing, but it's still all over the place.
>
> If you could check that you've addressed all the comments
> from previous patch review rounds that would make things
> faster.
>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH v14 2/9] target-avr: adding AVR CPU features/flavors

[Michael Rolnik]

Richard. Please stop reviewing it. It seems to be a wrong review.

On Mon, Aug 15, 2016, 6:31 PM Peter Maydell 
wrote:

> On 29 July 2016 at 16:32, Michael Rolnik  wrote:
> > Signed-off-by: Michael Rolnik 
> > ---
> >  target-avr/cpu.c | 319
> +--
> >  target-avr/cpu.h |  52 -
> >  target-avr/machine.c |  28 ++---
> >  3 files changed, 373 insertions(+), 26 deletions(-)
> >
> > diff --git a/target-avr/cpu.c b/target-avr/cpu.c
> > index c5ee2e9..fa15727 100644
> > --- a/target-avr/cpu.c
> > +++ b/target-avr/cpu.c
> > @@ -203,9 +203,300 @@ static void avr_cpu_class_init(ObjectClass *oc,
> void *data)
> >  dc->cannot_destroy_with_object_finalize_yet = true;
> >  }
> >
> > -static void avr_any_initfn(Object *obj)
>
> Please don't add code in one patch and then remove it in the next.
>
>
> > @@ -226,13 +531,7 @@ static gint avr_cpu_list_compare(gconstpointer a,
> gconstpointer b)
> >
> >  name_a = object_class_get_name(class_a);
> >  name_b = object_class_get_name(class_b);
> > -if (strcmp(name_a, "any-" TYPE_AVR_CPU) == 0) {
> > -return 1;
> > -} else if (strcmp(name_b, "any-" TYPE_AVR_CPU) == 0) {
> > -return -1;
> > -} else {
> > -return strcmp(name_a, name_b);
> > -}
> > +return strcmp(name_a, name_b);
> >  }
>
> Ditto.
>
> >
> >  static void avr_cpu_list_entry(gpointer data, gpointer user_data)
>
> > diff --git a/target-avr/machine.c b/target-avr/machine.c
> > index 9f20aed..2b005cc 100644
> > --- a/target-avr/machine.c
> > +++ b/target-avr/machine.c
> > @@ -44,8 +44,8 @@ static void put_sreg(QEMUFile *f, void *opaque, size_t
> size)
> >
> >  static const VMStateInfo vms_sreg = {
> >  .name = "sreg",
> > -.get  = get_sreg,
> > -.put  = put_sreg,
> > +.get = get_sreg,
> > +.put = put_sreg,
> >  };
>
> Please don't add code in one patch and then change its formatting
> in the next patch; just format it correctly to start with.
>
> Otherwise this patch looks OK.
>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH v14 2/9] target-avr: adding AVR CPU features/flavors

[Peter Maydell]

On 29 July 2016 at 16:32, Michael Rolnik  wrote:
> Signed-off-by: Michael Rolnik 
> ---
>  target-avr/cpu.c | 319 
> +--
>  target-avr/cpu.h |  52 -
>  target-avr/machine.c |  28 ++---
>  3 files changed, 373 insertions(+), 26 deletions(-)
>
> diff --git a/target-avr/cpu.c b/target-avr/cpu.c
> index c5ee2e9..fa15727 100644
> --- a/target-avr/cpu.c
> +++ b/target-avr/cpu.c
> @@ -203,9 +203,300 @@ static void avr_cpu_class_init(ObjectClass *oc, void 
> *data)
>  dc->cannot_destroy_with_object_finalize_yet = true;
>  }
>
> -static void avr_any_initfn(Object *obj)

Please don't add code in one patch and then remove it in the next.


> @@ -226,13 +531,7 @@ static gint avr_cpu_list_compare(gconstpointer a, 
> gconstpointer b)
>
>  name_a = object_class_get_name(class_a);
>  name_b = object_class_get_name(class_b);
> -if (strcmp(name_a, "any-" TYPE_AVR_CPU) == 0) {
> -return 1;
> -} else if (strcmp(name_b, "any-" TYPE_AVR_CPU) == 0) {
> -return -1;
> -} else {
> -return strcmp(name_a, name_b);
> -}
> +return strcmp(name_a, name_b);
>  }

Ditto.

>
>  static void avr_cpu_list_entry(gpointer data, gpointer user_data)

> diff --git a/target-avr/machine.c b/target-avr/machine.c
> index 9f20aed..2b005cc 100644
> --- a/target-avr/machine.c
> +++ b/target-avr/machine.c
> @@ -44,8 +44,8 @@ static void put_sreg(QEMUFile *f, void *opaque, size_t size)
>
>  static const VMStateInfo vms_sreg = {
>  .name = "sreg",
> -.get  = get_sreg,
> -.put  = put_sreg,
> +.get = get_sreg,
> +.put = put_sreg,
>  };

Please don't add code in one patch and then change its formatting
in the next patch; just format it correctly to start with.

Otherwise this patch looks OK.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v14 1/9] target-avr: AVR cores support is added.

[Peter Maydell]

On 29 July 2016 at 16:32, Michael Rolnik  wrote:
> 1. basic CPU structure
> 2. registers
> 3. no instructions
> 4. saving sreg, rampD, rampX, rampY, rampD, eind in HW representation
>
> Signed-off-by: Michael Rolnik 

> diff --git a/configure b/configure
> index f57fcc6..c4d58b4 100755
> --- a/configure
> +++ b/configure
> @@ -5641,6 +5641,8 @@ case "$target_name" in
>x86_64)
>  TARGET_BASE_ARCH=i386
>;;
> +  avr)
> +  ;;

I asked you to move this in my review of v12, but you haven't.

>alpha)
>;;
>arm|armeb)
> @@ -5837,6 +5839,9 @@ disas_config() {
>
>  for i in $ARCH $TARGET_BASE_ARCH ; do
>case "$i" in
> +  avr)
> +disas_config "AVR"
> +  ;;

Ditto.

>alpha)
>  disas_config "ALPHA"
>;;

> +#ifndef QEMU_AVR_CPU_QOM_H
> +#define QEMU_AVR_CPU_QOM_H
> +
> +#include "qom/cpu.h"
> +
> +#define TYPE_AVR_CPU "avr"
> +
> +#define AVR_CPU_CLASS(klass) \
> +OBJECT_CLASS_CHECK(AVRCPUClass, (klass), TYPE_AVR_CPU)
> +#define AVR_CPU(obj) \
> +OBJECT_CHECK(AVRCPU, (obj), TYPE_AVR_CPU)
> +#define AVR_CPU_GET_CLASS(obj) \
> +OBJECT_GET_CLASS(AVRCPUClass, (obj), TYPE_AVR_CPU)
> +
> +/**
> +*  AVRCPUClass:
> +*  @parent_realize: The parent class' realize handler.
> +*  @parent_reset: The parent class' reset handler.
> +*  @vr: Version Register value.
> +*
> +*  A AVR CPU model.
> + */

The spacing here is still wrong.

> +typedef struct AVRCPUClass {
> +CPUClass parent_class;
> +
> +DeviceRealize parent_realize;
> +void (*parent_reset)(CPUState *cpu);
> +} AVRCPUClass;
> +
> +/**
> +*  AVRCPU:
> +*  @env: #CPUAVRState
> +*
> +*  A AVR CPU.
> +*/

Ditto.

> +typedef struct AVRCPU {
> +/* < private > */
> +CPUState parent_obj;
> +/* < public > */
> +
> +CPUAVRState env;
> +} AVRCPU;

> +static bool avr_cpu_has_work(CPUState *cs)
> +{
> +AVRCPU *cpu = AVR_CPU(cs);
> +CPUAVRState *env = >env;
> +
> +return (cs->interrupt_request
> +&   (CPU_INTERRUPT_HARD
> +| CPU_INTERRUPT_RESET))
> +&&  cpu_interrupts_enabled(env);

I asked you to fix this spacing, but it's still all over the place.

If you could check that you've addressed all the comments
from previous patch review rounds that would make things
faster.

thanks
-- PMM

Re: [Qemu-devel] [PATCH] Revert "vhost-user: Attempt to fix a race with set_mem_table."

[Peter Maydell]

On 15 August 2016 at 14:35, Michael S. Tsirkin  wrote:
> This reverts commit 28ed5ef16384f12500abd3647973ee21b03cbe23.
>
> I still think it's the right thing to do, but
> tests have been failing sporadically.
>
> Revert for now, and hope to fix it before the release.
>
> Cc: Prerna Saxena 
> Cc: Peter Maydell 
> Cc: Marc-André Lureau 
> Signed-off-by: Michael S. Tsirkin 
> ---

Applied, thanks. I found my clang-on-x86-64 Linux Ubuntu xenial
build would hang in vhost-user/read-guest-mem after 10 or
so iterations, but with this revert applied it seems fine,
so I think this commit was definitely the culprit.

-- PMM

Re: [Qemu-devel] [PATCH v2] fpu: add mechanism to check for invalid long double formats

[Peter Maydell]

On 14 August 2016 at 01:33, Andrew Dutcher  wrote:
> The macro require_valid_floatx80(value, status) will check for malformed
> extended precision encodings, and if one is found, generate an
> invalid-operation exception and return NaN. This check has been added to
> the beginning of the basic 80-bit float arithmetic functions.

Hi; thanks for this patch. I think it's in general good,
but you haven't applied it to enough of the floatx80 functions.
We also need to check:
 * conversions from floatx80 to another float format
   (floatx80_to_float32/64/128)
 * conversions from floatx80 to integer
   (various floatx80_to_* functions)
 * comparisons
 * floatx80_scalbn (used in the FSCALE insn)
[basically we need to cover everything that the intel manual
 calls an "arithmetic instruction".]

I also have a few style issues which I'll remark on inline below.

> Version 2: fix code style

This sort of v1-to-v2 changelog should go below the '---' line,
so it doesn't go in the final commit message in git.

> Signed-off-by: Andrew Dutcher 
> ---
>  fpu/softfloat-specialize.h | 12 
>  fpu/softfloat.c| 11 +++
>  include/fpu/softfloat.h| 13 +
>  3 files changed, 36 insertions(+)
>
> diff --git a/fpu/softfloat-specialize.h b/fpu/softfloat-specialize.h
> index 43d0890..0e6ec25 100644
> --- a/fpu/softfloat-specialize.h
> +++ b/fpu/softfloat-specialize.h
> @@ -203,6 +203,18 @@ void float_raise(int8_t flags, float_status *status)
>  }
>
>  
> /*
> +| Asserts that the given value must be a valid floatx80 encoding. If The 
> given
> +| value is a pseudo-NaN, pseudo-infiinty, or un-normal, raise an invalid
> +| operation exception and cause the parent function to return NaN.
> +**/
> +
> +#define require_valid_floatx80(a, status)   \
> +if (floatx80_invalid_encoding((a))) {   \
> +float_raise(float_flag_invalid, (status));\
> +return floatx80_default_nan((status));\
> +}

Macros that incorporate hidden flow control tend to be bad for
readability, and the softfloat code is already dangerously
close to unreadable. I think it would be better to just expand
this macro out in the places where you're using it: saying
if (floatx80_invalid_encoding(a) || floatx80_invalid_encoding(b)) {
float_raise(float_flag_invalid, status);
return floatx80_default_nan(status);
}

is a few more lines but I think clearer.

> +
> +/*
>  | Internal canonical NaN format.
>  
> **/
>  typedef struct {
> diff --git a/fpu/softfloat.c b/fpu/softfloat.c
> index 9b1eccf..a921e5e 100644
> --- a/fpu/softfloat.c
> +++ b/fpu/softfloat.c
> @@ -5279,6 +5279,8 @@ floatx80 floatx80_add(floatx80 a, floatx80 b, 
> float_status *status)
>  {
>  flag aSign, bSign;
>
> +require_valid_floatx80(a, status);
> +require_valid_floatx80(b, status);
>  aSign = extractFloatx80Sign( a );
>  bSign = extractFloatx80Sign( b );
>  if ( aSign == bSign ) {
> @@ -5300,6 +5302,8 @@ floatx80 floatx80_sub(floatx80 a, floatx80 b, 
> float_status *status)
>  {
>  flag aSign, bSign;
>
> +require_valid_floatx80(a, status);
> +require_valid_floatx80(b, status);
>  aSign = extractFloatx80Sign( a );
>  bSign = extractFloatx80Sign( b );
>  if ( aSign == bSign ) {
> @@ -5323,6 +5327,8 @@ floatx80 floatx80_mul(floatx80 a, floatx80 b, 
> float_status *status)
>  int32_t aExp, bExp, zExp;
>  uint64_t aSig, bSig, zSig0, zSig1;
>
> +require_valid_floatx80(a, status);
> +require_valid_floatx80(b, status);
>  aSig = extractFloatx80Frac( a );
>  aExp = extractFloatx80Exp( a );
>  aSign = extractFloatx80Sign( a );
> @@ -5380,6 +5386,8 @@ floatx80 floatx80_div(floatx80 a, floatx80 b, 
> float_status *status)
>  uint64_t aSig, bSig, zSig0, zSig1;
>  uint64_t rem0, rem1, rem2, term0, term1, term2;
>
> +require_valid_floatx80(a, status);
> +require_valid_floatx80(b, status);
>  aSig = extractFloatx80Frac( a );
>  aExp = extractFloatx80Exp( a );
>  aSign = extractFloatx80Sign( a );
> @@ -5461,6 +5469,8 @@ floatx80 floatx80_rem(floatx80 a, floatx80 b, 
> float_status *status)
>  uint64_t aSig0, aSig1, bSig;
>  uint64_t q, term0, term1, alternateASig0, alternateASig1;
>
> +require_valid_floatx80(a, status);
> +require_valid_floatx80(b, status);
>  aSig0 = extractFloatx80Frac( a );
>  aExp = extractFloatx80Exp( a );
>  aSign = extractFloatx80Sign( a );
> @@ -5556,6 +5566,7 @@ floatx80 floatx80_sqrt(floatx80 a, float_status *status)
>  uint64_t aSig0, aSig1, zSig0, zSig1, doubleZSig0;
>  uint64_t 

[Qemu-devel] virnet: page allocation failure: order:0

[Philipp Hahn]

Hello,

this Sunday one of our virtual servers running linux-4.1.16 inside
OpenStack using qemu "crashed" while doing a backup using rsync to a
slow NFS server.
Crash here means that the server became unresponsive to network traffic:
- it was no longer able to contact the two LDAP servers
- no ssh login was possible
- the backup got stuck
- crond was still running and added process after process, leading to
~1.5k processes running after one day.

What I don't know is if the network problem was the cause or the
consequence. Because of that I want to understand why the follwoing
order=0 allocation failed:

> swapper/0: page allocation failure: order:0, mode:0x120

 4KiB
src/extern/linux/include/linux/gfp.h:
  18 #define ___GFP_HIGH»»···0x20u
  21 #define ___GFP_COLD»»···0x100u
  72 #define __GFP_HIGH»·((__force gfp_t)___GFP_HIGH)»···/* Should
access emergency pools? */


  75 #define __GFP_COLD»·((__force gfp_t)___GFP_COLD)»···/* Cache-cold
page required */



> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-ucs190-amd64 #1 Debian
4.1.6-1.190.201604142226

The kernel is 4.1.16 with some patches from Debian and some others.

> Hardware name: OpenStack Foundation OpenStack Nova, BIOS Bochs 01/01/2011
>    81597807 0120
>  8116b6e9 00018200 88021fffbb00 
>  88021fffbb08  88021fffab50 818164e0
> Call Trace:
>[] ? dump_stack+0x40/0x50
>  [] ? warn_alloc_failed+0xf9/0x150
>  [] ? __alloc_pages_nodemask+0x65a/0x9d0
>  [] ? alloc_pages_current+0xa4/0x120
>  [] ? skb_page_frag_refill+0xb7/0xe0
>  [] ? try_fill_recv+0x31b/0x610 [virtio_net]
>  [] ? virtnet_receive+0x580/0x890 [virtio_net]

Received network packet, but failed to copy from VirtIO to local kernel
memory.

>  [] ? virtnet_poll+0x26/0x90 [virtio_net]
>  [] ? net_rx_action+0x159/0x330
>  [] ? __do_softirq+0xde/0x260
>  [] ? irq_exit+0x95/0xa0
>  [] ? do_IRQ+0x64/0x110
>  [] ? common_interrupt+0x6e/0x6e
>[] ? mwait_idle+0x150/0x150
>  [] ? native_safe_halt+0x2/0x10
>  [] ? default_idle+0x1c/0xb0
>  [] ? cpu_startup_entry+0x314/0x3e0
>  [] ? start_kernel+0x48d/0x498
>  [] ? set_init_arg+0x50/0x50
>  [] ? early_idt_handler_array+0x117/0x120
>  [] ? early_idt_handler_array+0x117/0x120
>  [] ? x86_64_start_kernel+0x14a/0x159
> Mem-Info:
> active_anon:34861 inactive_anon:3120 isolated_anon:0
>  active_file:941577 inactive_file:946489 isolated_file:0
>  unevictable:974 dirty:2953 writeback:282206 unstable:1277
>  slab_reclaimable:55077 slab_unreclaimable:31365
>  mapped:3979 shmem:3986 pagetables:3163 bounce:0
>  free:9437 free_pcp:740 free_cma:0

Looks like enough memory is free

> Node 0 DMA free:15908kB min:20kB low:24kB high:28kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
> lowmem_reserve[]: 0 3492 7971 7971
> Node 0 DMA32 free:19532kB min:4968kB low:6208kB high:7452kB
active_anon:62328kB inactive_anon:5336kB active_file:1659704kB
inactive_file:1671236kB unevictable:2056kB isolated(anon):0kB
isolated(file):0kB present:3653624kB managed:3578476kB mlocked:2056kB
dirty:10472kB writeback:479692kB mapped:11892kB shmem:7132kB
slab_reclaimable:79832kB slab_unreclaimable:46784kB kernel_stack:2000kB
pagetables:4660kB unstable:2596kB bounce:0kB free_pcp:1080kB
local_pcp:120kB free_cma:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
> lowmem_reserve[]: 0 0 4478 4478
> Node 0 Normal free:2308kB min:6372kB low:7964kB high:9556kB
active_anon:77116kB inactive_anon:7144kB active_file:2106604kB
inactive_file:2114720kB unevictable:1840kB isolated(anon):0kB
isolated(file):0kB present:4718592kB managed:4586204kB mlocked:1840kB
dirty:1340kB writeback:649132kB mapped:4024kB shmem:8812kB
slab_reclaimable:140476kB slab_unreclaimable:78676kB kernel_stack:1888kB
pagetables:7992kB unstable:2512kB bounce:0kB free_pcp:1880kB
local_pcp:164kB free_cma:0kB writeback_tmp:0kB pages_scanned:768
all_unreclaimable? no
> lowmem_reserve[]: 0 0 0 0

Show also enough pages being available

> Node 0 DMA: 1*4kB (U) 0*8kB 0*16kB 1*32kB (U) 2*64kB (U) 1*128kB (U)
1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (EM) = 15908kB
> Node 0 DMA32: 4632*4kB (UEM) 81*8kB (UMR) 4*16kB (R) 1*32kB (R) 0*64kB
1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 19656kB
> Node 0 Normal: 315*4kB (UM) 1*8kB (R) 1*16kB (R) 1*32kB (R) 1*64kB (R)
1*128kB (R) 2*256kB (R) 1*512kB (R) 0*1024kB 0*2048kB 0*4096kB = 2532kB
> Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0
hugepages_size=2048kB

Here too.

> 1892811 total pagecache pages
> 0 pages in swap cache
> Swap cache stats: add 0, delete 0, find 0/0

Re: [Qemu-devel] [Patch v2 00/29] s390x CPU models: exposing features

[Cornelia Huck]

On Mon, 15 Aug 2016 16:03:04 +0200
Christian Borntraeger  wrote:

> On 08/15/2016 04:00 PM, David Hildenbrand wrote:
> > 
> > I'll wait a bit until sending out another series that fixes two minor style
> > problems.
> > 
> > What about > 80 chars per line. Is it okay for these definitions + function
> > prototype or a no-go?
> 
> As long as we are < 90 I think its better than wrapping.
> 

Agreed.

I think it's even ok to go over 90 if the alternative is breaking up
strings - which is extremely annoying for grepping.

Re: [Qemu-devel] [PATCH v10 00/11] Provide a QOM-based authorization API

[no-reply]

Hi,

Your 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.

Message-id: 1471270945-19975-1-git-send-email-berra...@redhat.com
Subject: [Qemu-devel] [PATCH v10 00/11] Provide a QOM-based authorization API
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
make J=8 docker-test-quick@centos6

# we need CURL DPRINTF patch
# http://patchew.org/QEMU/1470027888-24381-1-git-send-email-famz%40redhat.com/
#make J=8 docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
2b42606 qmp: add support for mixed typed input visitor
03ccf4a util: add QAuthZPAM object type for authorizing using PAM
681b2e7 acl: delete existing ACL implementation
3c99fc6 util: add QAuthZSimple object type for a simple access control list
5517080 util: add QAuthZ object as an authorization base class
0393e1c qom: support arbitrary non-scalar properties with -object
f63ef93 qapi: add a QmpInputVisitor that does string conversion
650ee1f qapi: rename QmpOutputVisitor to QObjectOutputVisitor
2a1a17d qapi: rename QmpInputVisitor to QObjectInputVisitor
d0ded29 option: make parse_option_bool/number non-static
3aebeb5 qdict: implement a qdict_crumple method for un-flattening a dict

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
  BUILD centos6
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPY RUNNER
  RUN test-quick in centos6
No C++ compiler available; disabling C++ specific optional code
Install prefix/tmp/qemu-test/src/tests/docker/install
BIOS directory/tmp/qemu-test/src/tests/docker/install/share/qemu
binary directory  /tmp/qemu-test/src/tests/docker/install/bin
library directory /tmp/qemu-test/src/tests/docker/install/lib
module directory  /tmp/qemu-test/src/tests/docker/install/lib/qemu
libexec directory /tmp/qemu-test/src/tests/docker/install/libexec
include directory /tmp/qemu-test/src/tests/docker/install/include
config directory  /tmp/qemu-test/src/tests/docker/install/etc
local state directory   /tmp/qemu-test/src/tests/docker/install/var
Manual directory  /tmp/qemu-test/src/tests/docker/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 -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -g 
QEMU_CFLAGS   -I/usr/include/pixman-1-fPIE -DPIE -m64 -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  -Wendif-labels -Wmissing-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
PAM   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  supportno
Documentation no
PIE   yes
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support   yes
RDMA support  no
TCG interpreter   no
fdt support   yes
preadv supportyes
fdatasync yes
madvise   yes
posix_madvise yes
uuid support  no
libcap-ng support no
vhost-net support yes
vhost-scsi support yes
Trace backendslog
spice support no 
rbd support   no
xfsctl supportno
smartcard support no
libusbno
usb net redir no
OpenGL supportno
OpenGL dmabufsno
libiscsi support  no
libnfs supportno
build guest agent yes
QGA VSS support   no
QGA w32 disk info no
QGA MSI support   no
seccomp support   no
coroutine backend 

Re: [Qemu-devel] [PATCH v10 00/11] Provide a QOM-based authorization API

[no-reply]

Hi,

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

Message-id: 1471270945-19975-1-git-send-email-berra...@redhat.com
Subject: [Qemu-devel] [PATCH v10 00/11] Provide a QOM-based authorization API
Type: series

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

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

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/1471270945-19975-1-git-send-email-berra...@redhat.com -> 
patchew/1471270945-19975-1-git-send-email-berra...@redhat.com
Switched to a new branch 'test'
2b42606 qmp: add support for mixed typed input visitor
03ccf4a util: add QAuthZPAM object type for authorizing using PAM
681b2e7 acl: delete existing ACL implementation
3c99fc6 util: add QAuthZSimple object type for a simple access control list
5517080 util: add QAuthZ object as an authorization base class
0393e1c qom: support arbitrary non-scalar properties with -object
f63ef93 qapi: add a QmpInputVisitor that does string conversion
650ee1f qapi: rename QmpOutputVisitor to QObjectOutputVisitor
2a1a17d qapi: rename QmpInputVisitor to QObjectInputVisitor
d0ded29 option: make parse_option_bool/number non-static
3aebeb5 qdict: implement a qdict_crumple method for un-flattening a dict

=== OUTPUT BEGIN ===
Checking PATCH 1/11: qdict: implement a qdict_crumple method for un-flattening 
a dict...
Checking PATCH 2/11: option: make parse_option_bool/number non-static...
Checking PATCH 3/11: qapi: rename QmpInputVisitor to QObjectInputVisitor...
ERROR: open brace '{' following struct go on the same line
#572: FILE: qapi/qobject-input-visitor.c:27:
+typedef struct StackObject
+{

ERROR: open brace '{' following struct go on the same line
#583: FILE: qapi/qobject-input-visitor.c:38:
+struct QObjectInputVisitor
+{

WARNING: line over 80 characters
#2480: FILE: tests/test-qobject-input-strict.c:94:
+v = validate_test_init(data, "{ 'integer': -42, 'boolean': true, 'string': 
'foo' }");

ERROR: line over 90 characters
#2508: FILE: tests/test-qobject-input-strict.c:122:
+v = validate_test_init(data, "[ { 'string': 'string0', 'integer': 42 }, { 
'string': 'string1', 'integer': 43 }, { 'string': 'string2', 'integer': 44 } 
]");

ERROR: line over 90 characters
#2561: FILE: tests/test-qobject-input-strict.c:175:
+v = validate_test_init(data, "{ 'integer': -42, 'boolean': true, 'string': 
'foo', 'extra': 42 }");

ERROR: line over 90 characters
#2575: FILE: tests/test-qobject-input-strict.c:189:
+v = validate_test_init(data, "{ 'string0': 'string0', 'dict1': { 
'string1': 'string1', 'dict2': { 'userdef1': { 'integer': 42, 'string': 
'string', 'extra': [42, 23, {'foo':'bar'}] }, 'string2': 'string2'}}}");

ERROR: line over 90 characters
#2589: FILE: tests/test-qobject-input-strict.c:203:
+v = validate_test_init(data, "[ { 'string': 'string0', 'integer': 42 }, { 
'string': 'string1', 'integer': 43 }, { 'string': 'string2', 'integer': 44, 
'extra': 'ggg' } ]");

WARNING: line over 80 characters
#2618: FILE: tests/test-qobject-input-strict.c:232:
+v = validate_test_init(data, "{ 'string': 'c', 'integer': 41, 'boolean': 
true }");

ERROR: line over 90 characters
#2633: FILE: tests/test-qobject-input-strict.c:247:
+v = validate_test_init(data, "{ 'integer': 42, 'string': 'c', 'string1': 
'd', 'string2': 'e' }");

ERROR: line over 90 characters
#2677: FILE: tests/test-qobject-input-strict.c:291:
+   void (*test_func)(TestInputVisitorData *data, 
const void *user_data))

ERROR: line over 90 characters
#2900: FILE: tests/test-qobject-input-visitor.c:173:
+v = visitor_input_test_init(data, "{ 'integer': -42, 'boolean': true, 
'string': 'foo' }");

ERROR: line over 90 characters
#2941: FILE: tests/test-qobject-input-visitor.c:214:
+v = visitor_input_test_init(data, "[ { 'string': 'string0', 'integer': 42 
}, { 'string': 'string1', 'integer': 43 }, { 'string': 'string2', 'integer': 44 
} ]");

ERROR: line over 90 characters
#2981: FILE: tests/test-qobject-input-visitor.c:254:
+v = visitor_input_test_init(data, "{ 'integer': -42, 'boolean': true, 
'string': 'foo' }");

ERROR: line over 90 characters
#3478: FILE: tests/test-qobject-input-visitor.c:751:
+   void (*test_func)(TestInputVisitorData 
*data, const void *user_data))

total: 12 errors, 2 warnings, 1864 lines checked

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

Checking PATCH 4/11: qapi: rename QmpOutputVisitor to 

[Qemu-devel] [PATCH v10 10/11] util: add QAuthZPAM object type for authorizing using PAM

[Daniel P. Berrange]

Add an authorization backend that talks to PAM to check
whether the user identity is allowed. This only uses the
PAM account validation facility, which is essentially
just a check to see if the provided username is permitted
access. It doesn't use the authentication or session
parts of PAM, since that's dealt with by the relevant
part of QEMU (eg VNC server).

Consider starting QEMU with a VNC server and telling it to
use TLS with x509 client certificates and configuring it to
use an ACL to validate the x509 distinguished name. IN this
example we're telling it to use PAM for the ACL impl with
a service name of "qemu-vnc"

 $ qemu-system-x86_64 \
 -object tls-creds-x509,id=tls0,dir=/home/berrange/security/qemutls,\
 endpoint=server,verify-peer=yes \
 -object authz-pam,id=acl0,service=qemu-vnc \
 -vnc :1,tls-creds=tls0,tls-acl=acl0

This requires an /etc/pam/qemu-vnc file to be created with
the auth rules. A very simple file based whitelist can be
setup using

  $ cat > /etc/pam/qemu-vnc < /etc/qemu/vnc.allow <
---
 configure|  36 
 include/qemu/authz-pam.h |  98 +++
 util/Makefile.objs   |   3 +
 util/authz-pam.c | 148 +++
 4 files changed, 285 insertions(+)
 create mode 100644 include/qemu/authz-pam.h
 create mode 100644 util/authz-pam.c

diff --git a/configure b/configure
index 8d84919..ec1d9b1 100755
--- a/configure
+++ b/configure
@@ -312,6 +312,7 @@ nettle=""
 nettle_kdf="no"
 gcrypt=""
 gcrypt_kdf="no"
+pam=""
 vte=""
 virglrenderer=""
 tpm="yes"
@@ -1112,6 +1113,10 @@ for opt do
   ;;
   --enable-gcrypt) gcrypt="yes"
   ;;
+  --disable-pam) pam="no"
+  ;;
+  --enable-pam) pam="yes"
+  ;;
   --enable-rdma) rdma="yes"
   ;;
   --disable-rdma) rdma="no"
@@ -1332,6 +1337,7 @@ disabled with --disable-FEATURE, default is enabled if 
available:
   gnutls  GNUTLS cryptography support
   nettle  nettle cryptography support
   gcrypt  libgcrypt cryptography support
+  pam PAM access control
   sdl SDL UI
   --with-sdlabi select preferred SDL ABI 1.2 or 2.0
   gtk gtk UI
@@ -2396,6 +2402,32 @@ fi
 
 
 ##
+# PAM probe
+
+if test "x$pam" != "no"; then
+cat > $TMPC <
+#include 
+int main(void) {
+   const char *service_name = "qemu";
+   const char *user = "frank";
+   const struct pam_conv *pam_conv = NULL;
+   pam_handle_t *pamh = NULL;
+   pam_start(service_name, user, pam_conv, );
+}
+EOF
+if compile_prog "" "-lpam" ; then
+   pam=yes
+else
+   if test "$pam" = "yes"; then
+   feature_not_found "PAM" "Install pam-devel"
+   else
+   pam=no
+   fi
+fi
+fi
+
+##
 # getifaddrs (for tests/test-io-channel-socket )
 
 have_ifaddrs_h=yes
@@ -4819,6 +4851,7 @@ echo "libgcrypt kdf $gcrypt_kdf"
 echo "nettle$nettle $(echo_version $nettle $nettle_version)"
 echo "nettle kdf$nettle_kdf"
 echo "libtasn1  $tasn1"
+echo "PAM   $pam"
 echo "curses support$curses"
 echo "virgl support $virglrenderer"
 echo "curl support  $curl"
@@ -5198,6 +5231,9 @@ fi
 if test "$tasn1" = "yes" ; then
   echo "CONFIG_TASN1=y" >> $config_host_mak
 fi
+if test "$pam" = "yes" ; then
+echo "CONFIG_PAM=y" >> $config_host_mak
+fi
 if test "$have_ifaddrs_h" = "yes" ; then
 echo "HAVE_IFADDRS_H=y" >> $config_host_mak
 fi
diff --git a/include/qemu/authz-pam.h b/include/qemu/authz-pam.h
new file mode 100644
index 000..dba0289
--- /dev/null
+++ b/include/qemu/authz-pam.h
@@ -0,0 +1,98 @@
+/*
+ * QEMU pam authorization driver
+ *
+ * Copyright (c) 2016 Red Hat, Inc.
+ *
+ * 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 .
+ *
+ */
+
+#ifndef QAUTHZ_PAM_H__
+#define QAUTHZ_PAM_H__
+
+#include "qemu/authz.h"
+
+
+#define TYPE_QAUTHZ_PAM "authz-pam"
+
+#define QAUTHZ_PAM_CLASS(klass) \
+ OBJECT_CLASS_CHECK(QAuthZPamClass, (klass), \
+TYPE_QAUTHZ_PAM)
+#define QAUTHZ_PAM_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(QAuthZPamClass, (obj), \
+  TYPE_QAUTHZ_PAM)
+#define QAUTHZ_PAM(obj) \
+ INTERFACE_CHECK(QAuthZPam, (obj), \
+ TYPE_QAUTHZ_PAM)
+
+typedef struct QAuthZPam QAuthZPam;
+typedef 

[Qemu-devel] [PATCH v10 08/11] util: add QAuthZSimple object type for a simple access control list

[Daniel P. Berrange]

Add a QAuthZSimple object type that implements the QAuthZ
interface. This simple built-in implementation maintains
a trivial access control list with a sequence of match
rules and a final default policy. This replicates the
functionality currently provided by the qemu_acl module.

To create an instance of this object via the QMP monitor,
the syntax used would be

  {
"execute": "object-add",
"arguments": {
  "qom-type": "authz-simple",
  "id": "auth0",
  "parameters": {
"rules": [
   { "match": "fred", "policy": "allow", "format": "exact" },
   { "match": "bob", "policy": "allow", "format": "exact" },
   { "match": "danb", "policy": "deny", "format": "glob" },
   { "match": "dan*", "policy": "allow", "format": "exact" },
],
"policy": "deny"
  }
}
  }

Or via the -object command line

  $QEMU \
 -object authz-simple,id=acl0,policy=deny,\
 rules.0.match=fred,rules.0.policy=allow,rules.0.format=exact,\
 rules.1.match=bob,rules.1.policy=allow,rules.1.format=exact,\
 rules.2.match=danb,rules.2.policy=deny,rules.2.format=glob,\
 rules.3.match=dan\*,rules.3.policy=allow,rules.3.format=exact

This sets up an authorization rule that allows 'fred',
'bob' and anyone whose name starts with 'dan', except
for 'danb'. Everyone unmatched is denied.

Reviewed-by: Marc-André Lureau 
Signed-off-by: Daniel P. Berrange 
---
 Makefile|   2 +-
 include/qemu/authz-simple.h | 115 
 qapi-schema.json|   6 +-
 qapi/util.json  |  47 +++
 tests/.gitignore|   1 +
 tests/Makefile.include  |   3 +
 tests/test-authz-simple.c   | 172 
 util/Makefile.objs  |   1 +
 util/authz-simple.c | 314 
 9 files changed, 659 insertions(+), 2 deletions(-)
 create mode 100644 include/qemu/authz-simple.h
 create mode 100644 qapi/util.json
 create mode 100644 tests/test-authz-simple.c
 create mode 100644 util/authz-simple.c

diff --git a/Makefile b/Makefile
index cd67cf2..b60cae0 100644
--- a/Makefile
+++ b/Makefile
@@ -293,7 +293,7 @@ qapi-modules = $(SRC_PATH)/qapi-schema.json 
$(SRC_PATH)/qapi/common.json \
$(SRC_PATH)/qapi/block.json $(SRC_PATH)/qapi/block-core.json \
$(SRC_PATH)/qapi/event.json $(SRC_PATH)/qapi/introspect.json \
$(SRC_PATH)/qapi/crypto.json $(SRC_PATH)/qapi/rocker.json \
-   $(SRC_PATH)/qapi/trace.json
+   $(SRC_PATH)/qapi/trace.json $(SRC_PATH)/qapi/util.json
 
 qapi-types.c qapi-types.h :\
 $(qapi-modules) $(SRC_PATH)/scripts/qapi-types.py $(qapi-py)
diff --git a/include/qemu/authz-simple.h b/include/qemu/authz-simple.h
new file mode 100644
index 000..30e78bd
--- /dev/null
+++ b/include/qemu/authz-simple.h
@@ -0,0 +1,115 @@
+/*
+ * QEMU simple authorization driver
+ *
+ * Copyright (c) 2016 Red Hat, Inc.
+ *
+ * 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 .
+ *
+ */
+
+#ifndef QAUTHZ_SIMPLE_H__
+#define QAUTHZ_SIMPLE_H__
+
+#include "qemu/authz.h"
+
+
+#define TYPE_QAUTHZ_SIMPLE "authz-simple"
+
+#define QAUTHZ_SIMPLE_CLASS(klass) \
+ OBJECT_CLASS_CHECK(QAuthZSimpleClass, (klass), \
+TYPE_QAUTHZ_SIMPLE)
+#define QAUTHZ_SIMPLE_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(QAuthZSimpleClass, (obj), \
+  TYPE_QAUTHZ_SIMPLE)
+#define QAUTHZ_SIMPLE(obj) \
+ INTERFACE_CHECK(QAuthZSimple, (obj), \
+ TYPE_QAUTHZ_SIMPLE)
+
+typedef struct QAuthZSimple QAuthZSimple;
+typedef struct QAuthZSimpleClass QAuthZSimpleClass;
+
+
+/**
+ * QAuthZSimple:
+ *
+ * This authorization driver provides a simple mechanism
+ * for granting access by matching user names against a
+ * list of globs. Each match rule has an associated policy
+ * and a catch all policy applies if no rule matches
+ *
+ * To create an instance of this class via QMP:
+ *
+ *  {
+ *"execute": "object-add",
+ *"arguments": {
+ *  "qom-type": "authz-simple",
+ *  "id": "auth0",
+ *  "parameters": {
+ *"rules": [
+ *   { "match": "fred", "policy": "allow", "format": "exact" },
+ *   { "match": "bob", "policy": "allow", "format": "exact" },
+ * 

Re: [Qemu-devel] [PATCH v3] help: Update help to remove misleading display information

[Markus Armbruster]

Colin Lord  writes:

> Updates the help messages to remove misleading information about SDL
> being the normal display used.
>
> Signed-off-by: Colin Lord 

Reviewed-by: Markus Armbruster 

[Qemu-devel] [PATCH v10 06/11] qom: support arbitrary non-scalar properties with -object

[Daniel P. Berrange]

The current -object command line syntax only allows for
creation of objects with scalar properties, or a list
with a fixed scalar element type. Objects which have
properties that are represented as structs in the QAPI
schema cannot be created using -object.

This is a design limitation of the way the OptsVisitor
is written. It simply iterates over the QemuOpts values
as a flat list. The support for lists is enabled by
allowing the same key to be repeated in the opts string.

It is not practical to extend the OptsVisitor to support
more complex data structures while also maintaining
the existing list handling behaviour that is relied upon
by other areas of QEMU.

Fortunately there is no existing object that implements
the UserCreatable interface that relies on the list
handling behaviour, so it is possible to swap out the
OptsVisitor for a different visitor implementation, so
-object supports non-scalar properties, thus leaving
other users of OptsVisitor unaffected.

The previously added qdict_crumple() method is able to
take a qdict containing a flat set of properties and
turn that into a arbitrarily nested set of dicts and
lists. By combining qemu_opts_to_qdict and qdict_crumple()
together, we can turn the opt string into a data structure
that is practically identical to that passed over QMP
when defining an object. The only difference is that all
the scalar values are represented as strings, rather than
strings, ints and bools. This is sufficient to let us
replace the OptsVisitor with the QMPInputVisitor for
use with -object.

Thus -object can now support non-scalar properties,
for example the QMP object

  {
"execute": "object-add",
"arguments": {
  "qom-type": "demo",
  "id": "demo0",
  "parameters": {
"foo": [
  { "bar": "one", "wizz": "1" },
  { "bar": "two", "wizz": "2" }
]
  }
}
  }

Would be creatable via the CLI now using

$QEMU \
  -object demo,id=demo0,\
  foo.0.bar=one,foo.0.wizz=1,\
  foo.1.bar=two,foo.1.wizz=2

Notice that this syntax is intentionally compatible
with that currently used by block drivers.

This is also wired up to work for the 'object_add' command
in the HMP monitor with the same syntax.

  (hmp) object_add demo,id=demo0,\
   foo.0.bar=one,foo.0.wizz=1,\
   foo.1.bar=two,foo.1.wizz=2

NB indentation should not be used with HMP commands, this
is just for convenient formatting in this commit message.

Signed-off-by: Daniel P. Berrange 
---
 hmp.c   |  16 +-
 include/qom/object_interfaces.h |  10 +-
 qmp.c   |   2 +-
 qom/object_interfaces.c |  45 --
 tests/check-qom-proplist.c  | 314 +++-
 5 files changed, 358 insertions(+), 29 deletions(-)

diff --git a/hmp.c b/hmp.c
index cc2056e..f1f75d0 100644
--- a/hmp.c
+++ b/hmp.c
@@ -25,7 +25,7 @@
 #include "qemu/sockets.h"
 #include "monitor/monitor.h"
 #include "monitor/qdev.h"
-#include "qapi/opts-visitor.h"
+#include "qapi/qobject-input-visitor.h"
 #include "qapi/qmp/qerror.h"
 #include "qapi/string-output-visitor.h"
 #include "qapi/util.h"
@@ -1693,20 +1693,14 @@ void hmp_netdev_del(Monitor *mon, const QDict *qdict)
 void hmp_object_add(Monitor *mon, const QDict *qdict)
 {
 Error *err = NULL;
-QemuOpts *opts;
 Visitor *v;
 Object *obj = NULL;
+QDict *pdict = qdict_clone_shallow(qdict);
 
-opts = qemu_opts_from_qdict(qemu_find_opts("object"), qdict, );
-if (err) {
-hmp_handle_error(mon, );
-return;
-}
-
-v = opts_visitor_new(opts);
-obj = user_creatable_add(qdict, v, );
+v = qobject_string_input_visitor_new(QOBJECT(pdict));
+obj = user_creatable_add(pdict, v, );
 visit_free(v);
-qemu_opts_del(opts);
+QDECREF(pdict);
 
 if (err) {
 hmp_handle_error(mon, );
diff --git a/include/qom/object_interfaces.h b/include/qom/object_interfaces.h
index 8b17f4d..2466e53 100644
--- a/include/qom/object_interfaces.h
+++ b/include/qom/object_interfaces.h
@@ -96,18 +96,24 @@ Object *user_creatable_add(const QDict *qdict,
  * user_creatable_add_type:
  * @type: the object type name
  * @id: the unique ID for the object
+ * @nested: whether to recurse into the visitor for properties
  * @qdict: the object properties
  * @v: the visitor
  * @errp: if an error occurs, a pointer to an area to store the error
  *
  * Create an instance of the user creatable object @type, placing
  * it in the object composition tree with name @id, initializing
- * it with properties from @qdict
+ * it with properties from @qdict.
+ *
+ * If the visitor is already positioned to read the properties
+ * in @qdict, @nested should be false. Conversely, if it is
+ * necessary to open/close a struct to read the properties in
+ * @qdict, @nested should be true.
  *
  * Returns: the newly created object or NULL on error
  */
 Object 

[Qemu-devel] [PATCH v10 07/11] util: add QAuthZ object as an authorization base class

[Daniel P. Berrange]

The current qemu_acl module provides a simple access control
list facility inside QEMU, which is used via a set of monitor
commands acl_show, acl_policy, acl_add, acl_remove & acl_reset.

Note there is no ability to create ACLs - the network services
(eg VNC server) were expected to create ACLs that they want to
check.

There is also no way to define ACLs on the command line, nor
potentially integrate with external authorization systems like
polkit, pam, ldap lookup, etc.

The QAuthZ object defines a minimal abstract QOM class that can
be subclassed for creating different authorization providers.

Signed-off-by: Daniel P. Berrange 
---
 MAINTAINERS  |  7 +
 Makefile |  1 +
 Makefile.objs|  2 ++
 Makefile.target  |  2 ++
 include/qemu/authz.h | 89 
 util/Makefile.objs   |  2 ++
 util/authz.c | 47 +++
 7 files changed, 150 insertions(+)
 create mode 100644 include/qemu/authz.h
 create mode 100644 util/authz.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b6fb84e..a6bb1db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1330,6 +1330,13 @@ F: include/qemu/throttle.h
 F: util/throttle.c
 L: qemu-bl...@nongnu.org
 
+Authorization
+M: Daniel P. Berrange 
+S: Maintained
+F: util/authz*
+F: include/qemu/authz*
+F: tests/test-authz-*
+
 Usermode Emulation
 --
 Overall
diff --git a/Makefile b/Makefile
index 50b4b3a..cd67cf2 100644
--- a/Makefile
+++ b/Makefile
@@ -148,6 +148,7 @@ endif
 dummy := $(call unnest-vars,, \
 stub-obj-y \
 util-obj-y \
+util-qom-obj-y \
 qga-obj-y \
 ivshmem-client-obj-y \
 ivshmem-server-obj-y \
diff --git a/Makefile.objs b/Makefile.objs
index 6d5ddcf..400f939 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -4,6 +4,8 @@ stub-obj-y = stubs/ crypto/
 util-obj-y = util/ qobject/ qapi/
 util-obj-y += qmp-introspect.o qapi-types.o qapi-visit.o qapi-event.o
 
+util-qom-obj-y += util/
+
 ###
 # block-obj-y is code used by both qemu system emulation and qemu-img
 
diff --git a/Makefile.target b/Makefile.target
index a440bcb..118c502 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -173,6 +173,7 @@ include $(SRC_PATH)/Makefile.objs
 dummy := $(call unnest-vars,,target-obj-y)
 target-obj-y-save := $(target-obj-y)
 dummy := $(call unnest-vars,.., \
+   util-qom-obj-y \
block-obj-y \
block-obj-m \
crypto-obj-y \
@@ -185,6 +186,7 @@ target-obj-y := $(target-obj-y-save)
 all-obj-y += $(common-obj-y)
 all-obj-y += $(target-obj-y)
 all-obj-y += $(qom-obj-y)
+all-obj-y += $(util-qom-obj-y)
 all-obj-$(CONFIG_SOFTMMU) += $(block-obj-y)
 all-obj-$(CONFIG_USER_ONLY) += $(crypto-aes-obj-y)
 all-obj-$(CONFIG_SOFTMMU) += $(crypto-obj-y)
diff --git a/include/qemu/authz.h b/include/qemu/authz.h
new file mode 100644
index 000..a000aa6
--- /dev/null
+++ b/include/qemu/authz.h
@@ -0,0 +1,89 @@
+/*
+ * QEMU authorization framework
+ *
+ * Copyright (c) 2016 Red Hat, Inc.
+ *
+ * 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 .
+ *
+ */
+
+#ifndef QAUTHZ_H__
+#define QAUTHZ_H__
+
+#include "qemu-common.h"
+#include "qapi/error.h"
+#include "qom/object.h"
+
+
+#define TYPE_QAUTHZ "authz"
+
+#define QAUTHZ_CLASS(klass) \
+ OBJECT_CLASS_CHECK(QAuthZClass, (klass), \
+TYPE_QAUTHZ)
+#define QAUTHZ_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(QAuthZClass, (obj), \
+  TYPE_QAUTHZ)
+#define QAUTHZ(obj) \
+ INTERFACE_CHECK(QAuthZ, (obj), \
+ TYPE_QAUTHZ)
+
+typedef struct QAuthZ QAuthZ;
+typedef struct QAuthZClass QAuthZClass;
+
+/**
+ * QAuthZ:
+ *
+ * The QAuthZ class defines an API contract to be used
+ * for providing an authorization driver for services
+ * with user identities.
+ */
+
+struct QAuthZ {
+Object parent_obj;
+};
+
+
+struct QAuthZClass {
+ObjectClass parent_class;
+
+bool (*is_allowed)(QAuthZ *authz,
+   const char *identity,
+   Error **errp);
+};
+
+
+/**
+ * qauthz_is_allowed:
+ * @authz: the authorization object
+ * @identity: the user identity to authorize
+ * @errp: 

[Qemu-devel] [PATCH v10 05/11] qapi: add a QmpInputVisitor that does string conversion

[Daniel P. Berrange]

Currently the QmpInputVisitor assumes that all scalar
values are directly represented as their final types.
ie it assumes an 'int' is using QInt, and a 'bool' is
using QBool.

This adds an alternative constructor for QmpInputVisitor
that will set it up such that it expects a QString for
all scalar types instead.

This makes it possible to use QmpInputVisitor with a
QDict produced from QemuOpts, where everything is in
string format.

Reviewed-by: Marc-André Lureau 
Signed-off-by: Daniel P. Berrange 
---
 include/qapi/qobject-input-visitor.h |  41 +-
 qapi/qobject-input-visitor.c | 115 +-
 tests/test-qobject-input-visitor.c   | 152 ++-
 3 files changed, 298 insertions(+), 10 deletions(-)

diff --git a/include/qapi/qobject-input-visitor.h 
b/include/qapi/qobject-input-visitor.h
index cde328d..aa911cb 100644
--- a/include/qapi/qobject-input-visitor.h
+++ b/include/qapi/qobject-input-visitor.h
@@ -19,12 +19,45 @@
 
 typedef struct QObjectInputVisitor QObjectInputVisitor;
 
-/*
- * Return a new input visitor that converts a QObject to a QAPI object.
+/**
+ * qobject_input_visitor_new:
+ * @obj: the input object to visit
+ * @strict: whether to require that all input keys are consumed
+ *
+ * Create a new input visitor that converts a QObject to a QAPI object.
+ *
+ * Any scalar values in the @obj input data structure should be in the
+ * required type already. i.e. if visiting a bool, the value should
+ * already be a QBool instance.
  *
- * Set @strict to reject a parse that doesn't consume all keys of a
- * dictionary; otherwise excess input is ignored.
+ * If @strict is set to true, then an error will be reported if any
+ * dict keys are not consumed during visitation.
+ *
+ * The returned input visitor should be released by calling
+ * visit_free() when no longer required.
+ *
+ * Returns: a new input visitor
  */
 Visitor *qobject_input_visitor_new(QObject *obj, bool strict);
 
+/**
+ * qobject_string_input_visitor_new:
+ * @obj: the input object to visit
+ *
+ * Create a new input visitor that converts a QObject to a QAPI object.
+ *
+ * Any scalar values in the @obj input data structure should always be
+ * represented as strings. i.e. if visiting a boolean, the value should
+ * be a QString whose contents represent a valid boolean.
+ *
+ * The visitor always operates in strict mode, requiring all dict keys
+ * to be consumed during visitation.
+ *
+ * The returned input visitor should be released by calling
+ * visit_free() when no longer required.
+ *
+ * Returns: a new input visitor
+ */
+Visitor *qobject_string_input_visitor_new(QObject *obj);
+
 #endif
diff --git a/qapi/qobject-input-visitor.c b/qapi/qobject-input-visitor.c
index 5ff3db3..b79c229 100644
--- a/qapi/qobject-input-visitor.c
+++ b/qapi/qobject-input-visitor.c
@@ -20,6 +20,7 @@
 #include "qemu-common.h"
 #include "qapi/qmp/types.h"
 #include "qapi/qmp/qerror.h"
+#include "qemu/cutils.h"
 
 #define QIV_STACK_SIZE 1024
 
@@ -263,6 +264,18 @@ static void qobject_input_type_int64(Visitor *v, const 
char *name, int64_t *obj,
 *obj = qint_get_int(qint);
 }
 
+static void qobject_input_type_int64_str(Visitor *v, const char *name,
+ int64_t *obj, Error **errp)
+{
+QObjectInputVisitor *qiv = to_qiv(v);
+QString *qstr = qobject_to_qstring(qobject_input_get_object(qiv, name,
+true));
+uint64_t ret;
+
+parse_option_number(name, qstr ? qstr->string : NULL, , errp);
+*obj = ret;
+}
+
 static void qobject_input_type_uint64(Visitor *v, const char *name,
   uint64_t *obj, Error **errp)
 {
@@ -279,6 +292,16 @@ static void qobject_input_type_uint64(Visitor *v, const 
char *name,
 *obj = qint_get_int(qint);
 }
 
+static void qobject_input_type_uint64_str(Visitor *v, const char *name,
+  uint64_t *obj, Error **errp)
+{
+QObjectInputVisitor *qiv = to_qiv(v);
+QString *qstr = qobject_to_qstring(qobject_input_get_object(qiv, name,
+true));
+
+parse_option_number(name, qstr ? qstr->string : NULL, obj, errp);
+}
+
 static void qobject_input_type_bool(Visitor *v, const char *name, bool *obj,
 Error **errp)
 {
@@ -294,6 +317,16 @@ static void qobject_input_type_bool(Visitor *v, const char 
*name, bool *obj,
 *obj = qbool_get_bool(qbool);
 }
 
+static void qobject_input_type_bool_str(Visitor *v, const char *name, bool 
*obj,
+Error **errp)
+{
+QObjectInputVisitor *qiv = to_qiv(v);
+QString *qstr = qobject_to_qstring(qobject_input_get_object(qiv, name,
+true));
+
+parse_option_bool(name, qstr ? qstr->string : NULL, 

[Qemu-devel] [PATCH v10 03/11] qapi: rename QmpInputVisitor to QObjectInputVisitor

[Daniel P. Berrange]

The QmpInputVisitor has no direct dependancy on QMP. It is
valid to use it anywhere that one has a QObject. Rename it
to better reflect its functionality as a generic QObject
to QAPI convertor.

Signed-off-by: Daniel P. Berrange 
---
 docs/qapi-code-gen.txt |   2 +-
 ...qmp-input-visitor.h => qobject-input-visitor.h} |  10 +-
 monitor.c  |   2 +-
 qapi/Makefile.objs |   2 +-
 ...qmp-input-visitor.c => qobject-input-visitor.c} | 171 +++--
 qmp.c  |   4 +-
 qom/qom-qobject.c  |   4 +-
 scripts/qapi-commands.py   |   4 +-
 tests/.gitignore   |   4 +-
 tests/Makefile.include |  12 +-
 tests/check-qnull.c|   4 +-
 tests/test-qmp-commands.c  |   4 +-
 ...-input-strict.c => test-qobject-input-strict.c} |   4 +-
 ...nput-visitor.c => test-qobject-input-visitor.c} |   4 +-
 tests/test-string-input-visitor.c  |   2 +-
 tests/test-visitor-serialization.c |   4 +-
 util/qemu-sockets.c|   2 +-
 17 files changed, 121 insertions(+), 118 deletions(-)
 rename include/qapi/{qmp-input-visitor.h => qobject-input-visitor.h} (63%)
 rename qapi/{qmp-input-visitor.c => qobject-input-visitor.c} (56%)
 rename tests/{test-qmp-input-strict.c => test-qobject-input-strict.c} (99%)
 rename tests/{test-qmp-input-visitor.c => test-qobject-input-visitor.c} (99%)

diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
index de298dc..a011872 100644
--- a/docs/qapi-code-gen.txt
+++ b/docs/qapi-code-gen.txt
@@ -1024,7 +1024,7 @@ Example:
 Visitor *v;
 UserDefOneList *arg1 = NULL;
 
-v = qmp_input_visitor_new(QOBJECT(args), true);
+v = qobject_input_visitor_new(QOBJECT(args), true);
 visit_start_struct(v, NULL, NULL, 0, );
 if (err) {
 goto out;
diff --git a/include/qapi/qmp-input-visitor.h 
b/include/qapi/qobject-input-visitor.h
similarity index 63%
rename from include/qapi/qmp-input-visitor.h
rename to include/qapi/qobject-input-visitor.h
index f3ff5f3..cde328d 100644
--- a/include/qapi/qmp-input-visitor.h
+++ b/include/qapi/qobject-input-visitor.h
@@ -11,20 +11,20 @@
  *
  */
 
-#ifndef QMP_INPUT_VISITOR_H
-#define QMP_INPUT_VISITOR_H
+#ifndef QOBJECT_INPUT_VISITOR_H
+#define QOBJECT_INPUT_VISITOR_H
 
 #include "qapi/visitor.h"
 #include "qapi/qmp/qobject.h"
 
-typedef struct QmpInputVisitor QmpInputVisitor;
+typedef struct QObjectInputVisitor QObjectInputVisitor;
 
 /*
- * Return a new input visitor that converts QMP to QAPI.
+ * Return a new input visitor that converts a QObject to a QAPI object.
  *
  * Set @strict to reject a parse that doesn't consume all keys of a
  * dictionary; otherwise excess input is ignored.
  */
-Visitor *qmp_input_visitor_new(QObject *obj, bool strict);
+Visitor *qobject_input_visitor_new(QObject *obj, bool strict);
 
 #endif
diff --git a/monitor.c b/monitor.c
index 5c00373..b151934 100644
--- a/monitor.c
+++ b/monitor.c
@@ -998,7 +998,7 @@ EventInfoList *qmp_query_events(Error **errp)
  * directly into QObject instead of first parsing it with
  * visit_type_SchemaInfoList() into a SchemaInfoList, then marshal it
  * to QObject with generated output marshallers, every time.  Instead,
- * we do it in test-qmp-input-visitor.c, just to make sure
+ * we do it in test-qobject-input-visitor.c, just to make sure
  * qapi-introspect.py's output actually conforms to the schema.
  */
 static void qmp_query_qmp_schema(QDict *qdict, QObject **ret_data,
diff --git a/qapi/Makefile.objs b/qapi/Makefile.objs
index 7ea4aeb..6ec7bdc 100644
--- a/qapi/Makefile.objs
+++ b/qapi/Makefile.objs
@@ -1,4 +1,4 @@
-util-obj-y = qapi-visit-core.o qapi-dealloc-visitor.o qmp-input-visitor.o
+util-obj-y = qapi-visit-core.o qapi-dealloc-visitor.o qobject-input-visitor.o
 util-obj-y += qmp-output-visitor.o qmp-registry.o qmp-dispatch.o
 util-obj-y += string-input-visitor.o string-output-visitor.o
 util-obj-y += opts-visitor.o qapi-clone-visitor.o
diff --git a/qapi/qmp-input-visitor.c b/qapi/qobject-input-visitor.c
similarity index 56%
rename from qapi/qmp-input-visitor.c
rename to qapi/qobject-input-visitor.c
index 64dd392..5ff3db3 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qobject-input-visitor.c
@@ -14,7 +14,7 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
-#include "qapi/qmp-input-visitor.h"
+#include "qapi/qobject-input-visitor.h"
 #include "qapi/visitor-impl.h"
 #include "qemu/queue.h"
 #include "qemu-common.h"
@@ -34,7 +34,7 @@ typedef struct StackObject
 QSLIST_ENTRY(StackObject) node;
 } StackObject;
 
-struct QmpInputVisitor
+struct QObjectInputVisitor
 {
 Visitor visitor;
 
@@ -49,14 +49,14 @@ struct QmpInputVisitor
 bool strict;
 };
 

[Qemu-devel] [PATCH v10 11/11] qmp: add support for mixed typed input visitor

[Daniel P. Berrange]

Add a qmp_mixed_input_visitor_new() method which returns
a QMP input visitor that accepts either strings or the
native data types.

Signed-off-by: Daniel P. Berrange 
---
 include/qapi/qobject-input-visitor.h | 22 
 qapi/qobject-input-visitor.c | 98 
 2 files changed, 120 insertions(+)

diff --git a/include/qapi/qobject-input-visitor.h 
b/include/qapi/qobject-input-visitor.h
index aa911cb..d9fe1d4 100644
--- a/include/qapi/qobject-input-visitor.h
+++ b/include/qapi/qobject-input-visitor.h
@@ -60,4 +60,26 @@ Visitor *qobject_input_visitor_new(QObject *obj, bool 
strict);
  */
 Visitor *qobject_string_input_visitor_new(QObject *obj);
 
+/**
+ * qobject_mixed_input_visitor_new:
+ * @obj: the input object to visit
+ * @strict: whether to require that all input keys are consumed
+ *
+ * Create a new input visitor that converts a QObject to a QAPI object.
+ *
+ * Any scalar values in the @obj input data structure can either be
+ * represented as the native data type, or as strings. ie if visiting
+ * a boolean, the value can be a QBoolean or a QString whose contents
+ * represent a valid boolean.
+ *
+ * If @strict is set to true, then an error will be reported if any
+ * dict keys are not consumed during visitation.
+ *
+ * The returned input visitor should be released by calling
+ * visit_free() when no longer required.
+ *
+ * Returns: a new input visitor
+ */
+Visitor *qobject_mixed_input_visitor_new(QObject *obj, bool strict);
+
 #endif
diff --git a/qapi/qobject-input-visitor.c b/qapi/qobject-input-visitor.c
index b79c229..d71c195 100644
--- a/qapi/qobject-input-visitor.c
+++ b/qapi/qobject-input-visitor.c
@@ -276,6 +276,19 @@ static void qobject_input_type_int64_str(Visitor *v, const 
char *name,
 *obj = ret;
 }
 
+static void qobject_input_type_int64_mixed(Visitor *v, const char *name,
+   int64_t *obj, Error **errp)
+{
+QObjectInputVisitor *qiv = to_qiv(v);
+QObject *qobj = qobject_input_get_object(qiv, name, true);
+
+if (qobj && qobj->type == QTYPE_QSTRING) {
+qobject_input_type_int64_str(v, name, obj, errp);
+} else {
+qobject_input_type_int64(v, name, obj, errp);
+}
+}
+
 static void qobject_input_type_uint64(Visitor *v, const char *name,
   uint64_t *obj, Error **errp)
 {
@@ -302,6 +315,19 @@ static void qobject_input_type_uint64_str(Visitor *v, 
const char *name,
 parse_option_number(name, qstr ? qstr->string : NULL, obj, errp);
 }
 
+static void qobject_input_type_uint64_mixed(Visitor *v, const char *name,
+uint64_t *obj, Error **errp)
+{
+QObjectInputVisitor *qiv = to_qiv(v);
+QObject *qobj = qobject_input_get_object(qiv, name, true);
+
+if (qobj && qobj->type == QTYPE_QSTRING) {
+qobject_input_type_uint64_str(v, name, obj, errp);
+} else {
+qobject_input_type_uint64(v, name, obj, errp);
+}
+}
+
 static void qobject_input_type_bool(Visitor *v, const char *name, bool *obj,
 Error **errp)
 {
@@ -327,6 +353,19 @@ static void qobject_input_type_bool_str(Visitor *v, const 
char *name, bool *obj,
 parse_option_bool(name, qstr ? qstr->string : NULL, obj, errp);
 }
 
+static void qobject_input_type_bool_mixed(Visitor *v, const char *name,
+  bool *obj, Error **errp)
+{
+QObjectInputVisitor *qiv = to_qiv(v);
+QObject *qobj = qobject_input_get_object(qiv, name, true);
+
+if (qobj && qobj->type == QTYPE_QSTRING) {
+qobject_input_type_bool_str(v, name, obj, errp);
+} else {
+qobject_input_type_bool(v, name, obj, errp);
+}
+}
+
 static void qobject_input_type_str(Visitor *v, const char *name, char **obj,
Error **errp)
 {
@@ -388,6 +427,19 @@ static void qobject_input_type_number_str(Visitor *v, 
const char *name,
"number");
 }
 
+static void qobject_input_type_number_mixed(Visitor *v, const char *name,
+double *obj, Error **errp)
+{
+QObjectInputVisitor *qiv = to_qiv(v);
+QObject *qobj = qobject_input_get_object(qiv, name, true);
+
+if (qobj && qobj->type == QTYPE_QSTRING) {
+qobject_input_type_number_str(v, name, obj, errp);
+} else {
+qobject_input_type_number(v, name, obj, errp);
+}
+}
+
 static void qobject_input_type_any(Visitor *v, const char *name, QObject **obj,
Error **errp)
 {
@@ -435,6 +487,20 @@ static void qobject_input_type_size_str(Visitor *v, const 
char *name,
"size");
 }
 
+static void qobject_input_type_size_mixed(Visitor *v, const char *name,
+  uint64_t *obj, Error **errp)
+{
+QObjectInputVisitor *qiv = to_qiv(v);
+QObject *qobj = qobject_input_get_object(qiv, name, true);
+
+   

Re: [Qemu-devel] [PATCH v7 04/16] qcow2: add qcow2_co_pwritev_compressed

[Pavel Butsykin]

On 08.08.2016 16:44, Kevin Wolf wrote:

Am 22.07.2016 um 10:17 hat Denis V. Lunev geschrieben:

From: Pavel Butsykin 

Added implementation of the qcow2_co_pwritev_compressed function that
will allow us to safely use compressed writes for the qcow2 from running
VMs.

Signed-off-by: Pavel Butsykin 
Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Denis V. Lunev 
CC: Jeff Cody 
CC: Markus Armbruster 
CC: Eric Blake 
CC: John Snow 
CC: Stefan Hajnoczi 
CC: Kevin Wolf 



  /* XXX: put compressed sectors first, then all the cluster aligned
 tables to avoid losing bytes in alignment */
-static int qcow2_write_compressed(BlockDriverState *bs, int64_t sector_num,
-  const uint8_t *buf, int nb_sectors)
+static coroutine_fn int
+qcow2_co_pwritev_compressed(BlockDriverState *bs, uint64_t offset,
+uint64_t bytes, QEMUIOVector *qiov)
  {
  BDRVQcow2State *s = bs->opaque;
+QEMUIOVector hd_qiov;
+struct iovec iov;
  z_stream strm;
  int ret, out_len;
-uint8_t *out_buf;
+uint8_t *buf, *out_buf;
  uint64_t cluster_offset;

-if (nb_sectors == 0) {
+if (bytes == 0) {
  /* align end of file to a sector boundary to ease reading with
 sector based I/Os */
  cluster_offset = bdrv_getlength(bs->file->bs);
  return bdrv_truncate(bs->file->bs, cluster_offset);
  }

-if (nb_sectors != s->cluster_sectors) {
+if (bytes != s->cluster_size) {
  ret = -EINVAL;

  /* Zero-pad last write if image size is not cluster aligned */
-if (sector_num + nb_sectors == bs->total_sectors &&
-nb_sectors < s->cluster_sectors) {
+if (offset + bytes == bs->total_sectors << BDRV_SECTOR_BITS &&
+bytes < s->cluster_size)
+{
  uint8_t *pad_buf = qemu_blockalign(bs, s->cluster_size);
  memset(pad_buf, 0, s->cluster_size);
-memcpy(pad_buf, buf, nb_sectors * BDRV_SECTOR_SIZE);
-ret = qcow2_write_compressed(bs, sector_num,
- pad_buf, s->cluster_sectors);
+qemu_iovec_to_buf(qiov, 0, pad_buf, s->cluster_size);


I think, bytes would be more exact than s->cluster_size here. Anyway,
shouldn't hurt because we stop at the end of the qiov anyway and its
size should match bytes.


Yes, I can send follow-up patches.



+iov = (struct iovec) {
+.iov_base   = pad_buf,
+.iov_len= s->cluster_size,
+};
+qemu_iovec_init_external(_qiov, , 1);
+ret = qcow2_co_pwritev_compressed(bs, offset, bytes, _qiov);
  qemu_vfree(pad_buf);
  }
  return ret;
  }


Kevin