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

2016-08-12 Thread Wei Huang
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;
 
 /* 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 */
 };
 
 static inline int arm_feature(CPUARMState *env, int feature)
diff --git a/target-arm/cpu64.c b/target-arm/cpu64.c
index 1635deb..19e8127 100644
--- a/target-arm/cpu64.c
+++ b/target-arm/cpu64.c
@@ -111,6 +111,9 @@ static void aarch64_a57_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_V8_PMULL);
 set_feature(>env, ARM_FEATURE_CRC);
 set_feature(>env, ARM_FEATURE_EL3);
+if (kvm_enabled()) {
+set_feature(>env, ARM_FEATURE_HOST_PMU);
+}
 cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A57;
 cpu->midr = 0x411fd070;
 cpu->revidr = 0x;
@@ -166,6 +169,9 @@ static void aarch64_a53_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_V8_PMULL);
 set_feature(>env, ARM_FEATURE_CRC);
 set_feature(>env, ARM_FEATURE_EL3);
+if (kvm_enabled()) {
+set_feature(>env, 

Re: [Qemu-devel] Hang bug in 80-bit float square root implementation

2016-08-12 Thread Andrew Dutcher
Alright! I'll test that new patch and submit it.

Thanks,
- Andrew

On Fri, Aug 12, 2016 at 4:01 AM, Peter Maydell  wrote:
> On 10 August 2016 at 04:35, Andrew Dutcher  wrote:
>> Hello!
>>
>> I ran into an issue where qemu (specifically, the unicorn engine)
>> would hang forever in the middle of the emulated square root
>> instruction under certain circumstances. I eventually tracked the
>> issue down to the square root of an "unnormal" long double, one
>> without the integer part bit set.
>>
>> Test case:
>>
>> cat > hang.s <> .intel_syntax noprefix
>>
>> .global _start
>> _start:
>>   xor eax,eax
>>   inc eax
>>   push eax
>>   push eax
>>   push eax
>>   fld tbyte ptr [esp]
>>   fsqrt
>>   int 0x80
>> EOF
>> as --32 hang.s -o hang.o
>> ld -melf_i386 hang.o -o hang
>> qemu-i386 ./hang
>>
>> qemu will hang! Assuming it jits the fsqrt as the soft float
>> implementation and doesn't just use a native fsqrt instruction. I have
>> no idea if qemu can do this, but it doesn't hurt to cover that base.
>
> Hi; thanks for this patch and test case. You're right that QEMU
> definitely shouldn't hang here, but I don't think this patch
> is the correct fix for it. As you say, there's been variation
> in how unnormals (80-bit-precision values with non-zero exponent
> field and the 'integer' bit zero) should be handled, but the
> Intel 64 and IA-32 architectures software developer's manual says
> that "The Intel 387 match coprocessor and later IA-32 processors
> generate an invalid-operation exception when [pseudo-NaNs,
> pseudo-infinities and un-normal numbers] are encountered as operands"
> (page 8-20 in the version of the doc I have). I checked on my
> x86 box (a Core i7-3770) and it does indeed do this. Since QEMU
> doesn't try to emulate the 287 we can stick to emulating just
> the "invalid-operation" behaviour and don't need to also try
> to emulate what the 287 did.
>
> I think that would look something like:
>
> if (floatx80_invalid_encoding(x)) {
> float_raise(float_flag_invalid, status);
> return floatx80_default_nan(status);
> }
>
> at the start of the relevant floatx80 functions (which is definitely
> more than just the sqrt function; would need to check the Intel
> docs for exactly which ones). floatx80_invalid_encoding()
> would be a new function that identifies the pseudo-NaN,
> pseudo-infinity and un-normal formats.
>
> (The other class of odd encoding is pseudo-denormal, but those
> are different because they are still supposed to be handled as
> inputs, they just aren't generated as outputs.)
>
>> I've never submitted a patch here before, so I hope this is the right
>> way to do it!
>
> It's pretty close. We have some documentation on patch formats
> and so on here: http://wiki.qemu.org/Contribute/SubmitAPatch
>
> The most important thing that you need to do is remember to
> add a "Signed-off-by:" line; we can fix up most other minor
> problems, but without the signed-off-by we can't accept the
> patch at all.
>
> thanks
> -- PMM



Re: [Qemu-devel] [Qemu-stable] [PATCH 00/56] Patch Round-up for stable 2.6.1, freeze on 2016-08-12

2016-08-12 Thread Gonglei
Hi Michael,

On 2016/8/10 4:04, Michael Roth wrote:
> Quoting Michael Roth (2016-08-08 16:03:31)
>> > Hi everyone,
>> > 
>> > The following new patches are queued for QEMU stable v2.6.1:
>> > 
>> >   https://github.com/mdroth/qemu/commits/stable-2.6-staging
>> > 
>> > The release is planned for 2016-08-17:
>> > 
>> >   http://wiki.qemu.org/Planning/2.6
>> > 
>> > Please respond here or CC qemu-sta...@nongnu.org on any patches you
>> > think should be included in the release.

I thinks this below patch should be included in v2.6.1:

commit 3fdd0ee393e26178a4892e101e60b011bbfaa9ea 
"timer: set vm_clock disabled default"

Regards,
-Gonglei




Re: [Qemu-devel] [PATCH v6 2/4] vfio: VFIO driver for mediated PCI device

2016-08-12 Thread Kirti Wankhede


On 8/13/2016 2:55 AM, Alex Williamson wrote:
> On Fri, 12 Aug 2016 23:27:01 +0530
> Kirti Wankhede  wrote:
> 
>> On 8/12/2016 12:13 AM, Alex Williamson wrote:
>>
>>>
>>> TBH, I don't see how providing a default implementation of
>>> validate_map_request() is useful.  How many mediated devices are going
>>> to want to identity map resources from the parent?  Even if they do, it
>>> seems we can only support a single mediated device per parent device
>>> since each will map the same parent resource offset. Let's not even try
>>> to define a default.  If we get a fault and the vendor driver hasn't
>>> provided a handler, send a SIGBUS.  I expect we should also allow
>>> vendor drivers to fill the mapping at mmap() time rather than expecting
>>> this map on fault scheme.  Maybe the mid-level driver should not even be
>>> interacting with mmap() and should let the vendor driver entirely
>>> determine the handling.
>>>  
>>
>> Should we go ahead with pass through mmap() call to vendor driver and
>> let vendor driver decide what to do in mmap() call, either
>> remap_pfn_range in mmap() or do fault on access and handle the fault in
>> their driver. In that case we don't need to track mappings in mdev core.
>> Let vendor driver do that on their own, right?
> 
> This sounds right to me, I don't think we want to impose either model
> on the vendor driver.  The vendor driver owns the vfio device file
> descriptor and is responsible for managing it should they expose mmap
> support for regions on the file descriptor.  They either need to insert
> mappings at the point where mmap() is called or setup fault handlers to
> insert them on demand.  If we can provide helper functions so that each
> vendor driver doesn't need to re-invent either of those, that would be
> a bonus.  Thanks,
> 

Since mmap() is going to be handled in vendor driver, let vendor driver
do their own tracking logic of mappings based on which way they decide
to go. No need to keep it in mdev coer module and try to handle all the
cases in one function.

Thanks,
Kirti


> Alex
> 



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

2016-08-12 Thread Kirti Wankhede


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

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.

For start callback, I can pass on the list of UUIDs as is to vendor
driver. Let vendor driver decide whether to iterate for each device and
commit resources or do it in one shot.

Thanks,
Kirti

>> and
>>
>> # echo "$UUID1" > /sys/devices/../mdev_destroy
>> # echo "$UUID2" > /sys/devices/../mdev_destroy
>>
>> Does this seems reasonable?
> 
> I've been hoping we could drop the instance numbers and create actual
> unique UUIDs per mediated device for a while ;)  Thanks,
> 
> Alex
> 



[Qemu-devel] [PULL 1/2] Xen: fix converity warning of xen_pt_config_init()

2016-08-12 Thread Stefano Stabellini
From: Cao jin 

emu_regs is a pointer, ARRAY_SIZE doesn't return what we expect.
Since the remaining message is enough for debugging, so just remove it.
Also tweaked the message a little.

Signed-off-by: Cao jin 
Signed-off-by: Stefano Stabellini 
Acked-by: Stefano Stabellini 
---
 hw/xen/xen_pt_config_init.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 9869ffd..6f18366 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -2049,9 +2049,8 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error 
**errp)
 for (j = 0; regs->size != 0; j++, regs++) {
 xen_pt_config_reg_init(s, reg_grp_entry, regs, );
 if (err) {
-error_append_hint(, "Failed to initialize %d/%zu"
-" reg 0x%x in grp_type = 0x%x (%d/%zu)",
-j, ARRAY_SIZE(xen_pt_emu_reg_grps[i].emu_regs),
+error_append_hint(, "Failed to init register %d"
+" offsets 0x%x in grp_type = 0x%x (%d/%zu)", j,
 regs->offset, xen_pt_emu_reg_grps[i].grp_type,
 i, ARRAY_SIZE(xen_pt_emu_reg_grps));
 error_propagate(errp, err);
-- 
1.9.1




[Qemu-devel] [PULL 2/2] xen: handle inbound migration of VMs without ioreq server pages

2016-08-12 Thread Stefano Stabellini
From: Paul Durrant 

VMs created on older versions on Xen will not have been provisioned with
pages to support creation of non-default ioreq servers. In this case
the ioreq server API is not supported and QEMU's only option is to fall
back to using the default ioreq server pages as it did prior to
commit 3996e85c ("Xen: Use the ioreq-server API when available").

This patch therefore changes the code in xen_common.h to stop considering
a failure of xc_hvm_create_ioreq_server() as a hard failure but simply
as an indication that the guest is too old to support the ioreq server
API. Instead a boolean is set to cause reversion to old behaviour such
that the default ioreq server is then used.

Signed-off-by: Paul Durrant 
Signed-off-by: Stefano Stabellini 
Acked-by: Anthony PERARD 
Acked-by: Stefano Stabellini 
---
 include/hw/xen/xen_common.h | 125 +++-
 trace-events|   1 +
 xen-hvm.c   |   6 +--
 3 files changed, 92 insertions(+), 40 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 640c31e..bd39287 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -107,6 +107,44 @@ static inline int xen_get_vmport_regs_pfn(xc_interface 
*xc, domid_t dom,
 
 #endif
 
+static inline int xen_get_default_ioreq_server_info(xc_interface *xc,
+domid_t dom,
+xen_pfn_t *ioreq_pfn,
+xen_pfn_t *bufioreq_pfn,
+evtchn_port_t
+*bufioreq_evtchn)
+{
+unsigned long param;
+int rc;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n");
+return -1;
+}
+
+*ioreq_pfn = param;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n");
+return -1;
+}
+
+*bufioreq_pfn = param;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
+  );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+return -1;
+}
+
+*bufioreq_evtchn = param;
+
+return 0;
+}
+
 /* Xen before 4.5 */
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 450
 
@@ -154,10 +192,9 @@ static inline void xen_unmap_pcidev(xc_interface *xc, 
domid_t dom,
 {
 }
 
-static inline int xen_create_ioreq_server(xc_interface *xc, domid_t dom,
-  ioservid_t *ioservid)
+static inline void xen_create_ioreq_server(xc_interface *xc, domid_t dom,
+   ioservid_t *ioservid)
 {
-return 0;
 }
 
 static inline void xen_destroy_ioreq_server(xc_interface *xc, domid_t dom,
@@ -171,35 +208,8 @@ static inline int xen_get_ioreq_server_info(xc_interface 
*xc, domid_t dom,
 xen_pfn_t *bufioreq_pfn,
 evtchn_port_t *bufioreq_evtchn)
 {
-unsigned long param;
-int rc;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n");
-return -1;
-}
-
-*ioreq_pfn = param;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n");
-return -1;
-}
-
-*bufioreq_pfn = param;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
-  );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
-return -1;
-}
-
-*bufioreq_evtchn = param;
-
-return 0;
+return xen_get_default_ioreq_server_info(xc, dom, ioreq_pfn, bufioreq_pfn,
+ bufioreq_evtchn);
 }
 
 static inline int xen_set_ioreq_server_state(xc_interface *xc, domid_t dom,
@@ -212,6 +222,8 @@ static inline int xen_set_ioreq_server_state(xc_interface 
*xc, domid_t dom,
 /* Xen 4.5 */
 #else
 
+static bool use_default_ioreq_server;
+
 static inline void xen_map_memory_section(xc_interface *xc, domid_t dom,
   ioservid_t ioservid,
   MemoryRegionSection *section)
@@ -220,6 +232,10 @@ static inline void xen_map_memory_section(xc_interface 
*xc, domid_t dom,
 ram_addr_t size = int128_get64(section->size);
 hwaddr end_addr = start_addr + size - 1;
 
+if (use_default_ioreq_server) {
+return;
+}
+
 trace_xen_map_mmio_range(ioservid, start_addr, 

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

2016-08-12 Thread Stefano Stabellini
Sorry, please disregard this pull request, I forgot to add my acked-by to
one of the commits. I'll resend shortly.

On Fri, 12 Aug 2016, 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
> 
> for you to fetch changes up to f7ca8a4fdcb478fdb0503c2d39b0b85160c913d9:
> 
>   xen: handle inbound migration of VMs without ioreq server pages (2016-08-12 
> 15:16:15 -0700)
> 
> 
> Xen 2016/08/12
> 
> 
> 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
> 
>  hw/xen/xen_pt_config_init.c |   5 +-
>  include/hw/xen/xen_common.h | 125 
> +++-
>  trace-events|   1 +
>  xen-hvm.c   |   6 +--
>  4 files changed, 94 insertions(+), 43 deletions(-)
> 



[Qemu-devel] [PULL 2/2] xen: handle inbound migration of VMs without ioreq server pages

2016-08-12 Thread Stefano Stabellini
From: Paul Durrant 

VMs created on older versions on Xen will not have been provisioned with
pages to support creation of non-default ioreq servers. In this case
the ioreq server API is not supported and QEMU's only option is to fall
back to using the default ioreq server pages as it did prior to
commit 3996e85c ("Xen: Use the ioreq-server API when available").

This patch therefore changes the code in xen_common.h to stop considering
a failure of xc_hvm_create_ioreq_server() as a hard failure but simply
as an indication that the guest is too old to support the ioreq server
API. Instead a boolean is set to cause reversion to old behaviour such
that the default ioreq server is then used.

Signed-off-by: Paul Durrant 
Signed-off-by: Stefano Stabellini 
Acked-by: Anthony PERARD 
Acked-by: Stefano Stabellini 
---
 include/hw/xen/xen_common.h | 125 +++-
 trace-events|   1 +
 xen-hvm.c   |   6 +--
 3 files changed, 92 insertions(+), 40 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 640c31e..bd39287 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -107,6 +107,44 @@ static inline int xen_get_vmport_regs_pfn(xc_interface 
*xc, domid_t dom,
 
 #endif
 
+static inline int xen_get_default_ioreq_server_info(xc_interface *xc,
+domid_t dom,
+xen_pfn_t *ioreq_pfn,
+xen_pfn_t *bufioreq_pfn,
+evtchn_port_t
+*bufioreq_evtchn)
+{
+unsigned long param;
+int rc;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n");
+return -1;
+}
+
+*ioreq_pfn = param;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n");
+return -1;
+}
+
+*bufioreq_pfn = param;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
+  );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+return -1;
+}
+
+*bufioreq_evtchn = param;
+
+return 0;
+}
+
 /* Xen before 4.5 */
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 450
 
@@ -154,10 +192,9 @@ static inline void xen_unmap_pcidev(xc_interface *xc, 
domid_t dom,
 {
 }
 
-static inline int xen_create_ioreq_server(xc_interface *xc, domid_t dom,
-  ioservid_t *ioservid)
+static inline void xen_create_ioreq_server(xc_interface *xc, domid_t dom,
+   ioservid_t *ioservid)
 {
-return 0;
 }
 
 static inline void xen_destroy_ioreq_server(xc_interface *xc, domid_t dom,
@@ -171,35 +208,8 @@ static inline int xen_get_ioreq_server_info(xc_interface 
*xc, domid_t dom,
 xen_pfn_t *bufioreq_pfn,
 evtchn_port_t *bufioreq_evtchn)
 {
-unsigned long param;
-int rc;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n");
-return -1;
-}
-
-*ioreq_pfn = param;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n");
-return -1;
-}
-
-*bufioreq_pfn = param;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
-  );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
-return -1;
-}
-
-*bufioreq_evtchn = param;
-
-return 0;
+return xen_get_default_ioreq_server_info(xc, dom, ioreq_pfn, bufioreq_pfn,
+ bufioreq_evtchn);
 }
 
 static inline int xen_set_ioreq_server_state(xc_interface *xc, domid_t dom,
@@ -212,6 +222,8 @@ static inline int xen_set_ioreq_server_state(xc_interface 
*xc, domid_t dom,
 /* Xen 4.5 */
 #else
 
+static bool use_default_ioreq_server;
+
 static inline void xen_map_memory_section(xc_interface *xc, domid_t dom,
   ioservid_t ioservid,
   MemoryRegionSection *section)
@@ -220,6 +232,10 @@ static inline void xen_map_memory_section(xc_interface 
*xc, domid_t dom,
 ram_addr_t size = int128_get64(section->size);
 hwaddr end_addr = start_addr + size - 1;
 
+if (use_default_ioreq_server) {
+return;
+}
+
 trace_xen_map_mmio_range(ioservid, start_addr, 

[Qemu-devel] [PULL 1/2] Xen: fix converity warning of xen_pt_config_init()

2016-08-12 Thread Stefano Stabellini
From: Cao jin 

emu_regs is a pointer, ARRAY_SIZE doesn't return what we expect.
Since the remaining message is enough for debugging, so just remove it.
Also tweaked the message a little.

Signed-off-by: Cao jin 
---
 hw/xen/xen_pt_config_init.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 9869ffd..6f18366 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -2049,9 +2049,8 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error 
**errp)
 for (j = 0; regs->size != 0; j++, regs++) {
 xen_pt_config_reg_init(s, reg_grp_entry, regs, );
 if (err) {
-error_append_hint(, "Failed to initialize %d/%zu"
-" reg 0x%x in grp_type = 0x%x (%d/%zu)",
-j, ARRAY_SIZE(xen_pt_emu_reg_grps[i].emu_regs),
+error_append_hint(, "Failed to init register %d"
+" offsets 0x%x in grp_type = 0x%x (%d/%zu)", j,
 regs->offset, xen_pt_emu_reg_grps[i].grp_type,
 i, ARRAY_SIZE(xen_pt_emu_reg_grps));
 error_propagate(errp, err);
-- 
1.9.1




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

2016-08-12 Thread Stefano Stabellini
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

for you to fetch changes up to f7ca8a4fdcb478fdb0503c2d39b0b85160c913d9:

  xen: handle inbound migration of VMs without ioreq server pages (2016-08-12 
15:16:15 -0700)


Xen 2016/08/12


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

 hw/xen/xen_pt_config_init.c |   5 +-
 include/hw/xen/xen_common.h | 125 +++-
 trace-events|   1 +
 xen-hvm.c   |   6 +--
 4 files changed, 94 insertions(+), 43 deletions(-)



[Qemu-devel] [PATCH] net: Constify the checksum functions

2016-08-12 Thread Benjamin Herrenschmidt
They never touch the buffer, it should be const, this helps when
drivers want to pass const pointers.

This is purely signature changes, there are no actual code changes.

Signed-off-by: Benjamin Herrenschmidt 
---
 include/net/checksum.h | 10 +-
 net/checksum.c |  6 +++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/net/checksum.h b/include/net/checksum.h
index 7df472c..091f547 100644
--- a/include/net/checksum.h
+++ b/include/net/checksum.h
@@ -21,20 +21,20 @@
 #include "qemu/bswap.h"
 struct iovec;
 
-uint32_t net_checksum_add_cont(int len, uint8_t *buf, int seq);
+uint32_t net_checksum_add_cont(int len, const uint8_t *buf, int seq);
 uint16_t net_checksum_finish(uint32_t sum);
 uint16_t net_checksum_tcpudp(uint16_t length, uint16_t proto,
- uint8_t *addrs, uint8_t *buf);
-void net_checksum_calculate(uint8_t *data, int length);
+ const uint8_t *addrs, const uint8_t *buf);
+void net_checksum_calculate(const uint8_t *data, int length);
 
 static inline uint32_t
-net_checksum_add(int len, uint8_t *buf)
+net_checksum_add(int len, const uint8_t *buf)
 {
 return net_checksum_add_cont(len, buf, 0);
 }
 
 static inline uint16_t
-net_raw_checksum(uint8_t *data, int length)
+net_raw_checksum(const uint8_t *data, int length)
 {
 return net_checksum_finish(net_checksum_add(length, data));
 }
diff --git a/net/checksum.c b/net/checksum.c
index 23323b0..2da95bd 100644
--- a/net/checksum.c
+++ b/net/checksum.c
@@ -20,7 +20,7 @@
 #include "net/checksum.h"
 #include "net/eth.h"
 
-uint32_t net_checksum_add_cont(int len, uint8_t *buf, int seq)
+uint32_t net_checksum_add_cont(int len, const uint8_t *buf, int seq)
 {
 uint32_t sum = 0;
 int i;
@@ -43,7 +43,7 @@ uint16_t net_checksum_finish(uint32_t sum)
 }
 
 uint16_t net_checksum_tcpudp(uint16_t length, uint16_t proto,
- uint8_t *addrs, uint8_t *buf)
+ const uint8_t *addrs, const uint8_t *buf)
 {
 uint32_t sum = 0;
 
@@ -53,7 +53,7 @@ uint16_t net_checksum_tcpudp(uint16_t length, uint16_t proto,
 return net_checksum_finish(sum);
 }
 
-void net_checksum_calculate(uint8_t *data, int length)
+void net_checksum_calculate(const uint8_t *data, int length)
 {
 int mac_hdr_len, ip_len;
 struct ip_header *ip;




Re: [Qemu-devel] [PATCH] xen: handle inbound migration of VMs without ioreq server pages

2016-08-12 Thread Stefano Stabellini
On Fri, 12 Aug 2016, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 11 August 2016 21:07
> > To: Paul Durrant
> > Cc: Anthony Perard; xen-de...@lists.xenproject.org; qemu-
> > de...@nongnu.org; Stefano Stabellini
> > Subject: RE: [PATCH] xen: handle inbound migration of VMs without ioreq
> > server pages
> > 
> > On Tue, 9 Aug 2016, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > > > Sent: 09 August 2016 16:19
> > > > To: Paul Durrant
> > > > Cc: xen-de...@lists.xenproject.org; qemu-devel@nongnu.org; Stefano
> > > > Stabellini
> > > > Subject: Re: [PATCH] xen: handle inbound migration of VMs without
> > ioreq
> > > > server pages
> > > >
> > > > On Mon, Aug 01, 2016 at 10:16:25AM +0100, Paul Durrant wrote:
> > > > > VMs created on older versions on Xen will not have been provisioned
> > with
> > > > > pages to support creation of non-default ioreq servers. In this case
> > > > > the ioreq server API is not supported and QEMU's only option is to 
> > > > > fall
> > > > > back to using the default ioreq server pages as it did prior to
> > > > > commit 3996e85c ("Xen: Use the ioreq-server API when available").
> > > > >
> > > > > This patch therefore changes the code in xen_common.h to stop
> > > > considering
> > > > > a failure of xc_hvm_create_ioreq_server() as a hard failure but simply
> > > > > as an indication that the guest is too old to support the ioreq server
> > > > > API. Instead a boolean is set to cause reversion to old behaviour such
> > > > > that the default ioreq server is then used.
> > > > >
> > > > > Signed-off-by: Paul Durrant 
> > > > > Cc: Stefano Stabellini 
> > > > > Cc: Anthony Perard 
> > > >
> > > > There are just two lines too long:
> > > >
> > > > WARNING: line over 80 characters
> > > > #31: FILE: include/hw/xen/xen_common.h:110:
> > > > +static inline int xen_get_default_ioreq_server_info(xc_interface *xc,
> > > > domid_t dom,
> > > >
> > > > WARNING: line over 80 characters
> > > > #34: FILE: include/hw/xen/xen_common.h:113:
> > > > +evtchn_port_t 
> > > > *bufioreq_evtchn)
> > > >
> > > > With that fixed: Acked-by: Anthony PERARD
> > 
> > > >
> > > > Thanks,
> > > >
> > >
> > > Ok, I'll post v2 with those fixes and your ack. Thanks,
> > 
> > Thank you for fixing this bug and Thanks Anthony for the review.
> > 
> > I was about to commit it but my sense of style rebelled: I really don't
> > like all the if statements. Too many! Sorry for coming in so late in
> > commenting on a patch, I realize that it is unfair.
> > 
> > Would you be up for rewriting the fix so that instead of introducing
> > 
> > if (use_default_ioreq_server) {
> > return;
> > }
> > 
> > in many functions, we turn xc_hvm_* calls into function pointers calls
> > that get set to the right behavior depending on the success of
> > xc_hvm_create_ioreq_server?
> > 
> > 
> > The call sites would be something like:
> > 
> > ioreq_server->unmap_io_range_from_ioreq_server(xc, dom, ioservid, 0,
> > start_addr, end_addr);
> > 
> > At boot time, if xc_hvm_create_ioreq_server returns error:
> > 
> > ioreq_server = empty_stubs_functions;
> > 
> > else
> > 
> > ioreq_server = useful_functions;
> > 
> > 
> > What do you guys think?
> 
> Personally I don't think it's worth it. This is not a performance critical 
> codepath but if you insist I will re-factor the code.

All right, given that Anthony already acked it, it's two vs. one. I'll
commit it as is.



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

2016-08-12 Thread Colin Lord
Updates the help messages to remove misleading information about SDL
being the normal display used.

Signed-off-by: Colin Lord 
---
v3: Try to make help more general to cover all cases nicely.
 qemu-options.hx | 38 +-
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index a71aaf8..c093a59 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -982,13 +982,14 @@ DEF("nographic", 0, QEMU_OPTION_nographic,
 STEXI
 @item -nographic
 @findex -nographic
-Normally, QEMU uses SDL to display the VGA output. With this option,
-you can totally disable graphical output so that QEMU is a simple
-command line application. The emulated serial port is redirected on
-the console and muxed with the monitor (unless redirected elsewhere
-explicitly). Therefore, you can still use QEMU to debug a Linux kernel
-with a serial console.  Use @key{C-a h} for help on switching between
-the console and monitor.
+Normally, if QEMU is compiled with graphical window support, it displays
+output such as guest graphics, guest console, and the QEMU monitor in a
+window. With this option, you can totally disable graphical output so
+that QEMU is a simple command line application. The emulated serial port
+is redirected on the console and muxed with the monitor (unless
+redirected elsewhere explicitly). Therefore, you can still use QEMU to
+debug a Linux kernel with a serial console. Use @key{C-a h} for help on
+switching between the console and monitor.
 ETEXI
 
 DEF("curses", 0, QEMU_OPTION_curses,
@@ -997,9 +998,11 @@ DEF("curses", 0, QEMU_OPTION_curses,
 STEXI
 @item -curses
 @findex -curses
-Normally, QEMU uses SDL to display the VGA output.  With this option,
-QEMU can display the VGA output when in text mode using a
-curses/ncurses interface.  Nothing is displayed in graphical mode.
+Normally, if QEMU is compiled with graphical window support, it displays
+output such as guest graphics, guest console, and the QEMU monitor in a
+window. With this option, QEMU can display the VGA output when in text
+mode using a curses/ncurses interface. Nothing is displayed in graphical
+mode.
 ETEXI
 
 DEF("no-frame", 0, QEMU_OPTION_no_frame,
@@ -1243,13 +1246,14 @@ DEF("vnc", HAS_ARG, QEMU_OPTION_vnc ,
 STEXI
 @item -vnc @var{display}[,@var{option}[,@var{option}[,...]]]
 @findex -vnc
-Normally, QEMU uses SDL to display the VGA output.  With this option,
-you can have QEMU listen on VNC display @var{display} and redirect the VGA
-display over the VNC session.  It is very useful to enable the usb
-tablet device when using this option (option @option{-usbdevice
-tablet}). When using the VNC display, you must use the @option{-k}
-parameter to set the keyboard layout if you are not using en-us. Valid
-syntax for the @var{display} is
+Normally, if QEMU is compiled with graphical window support, it displays
+output such as guest graphics, guest console, and the QEMU monitor in a
+window. With this option, you can have QEMU listen on VNC display
+@var{display} and redirect the VGA display over the VNC session. It is
+very useful to enable the usb tablet device when using this option
+(option @option{-usbdevice tablet}). When using the VNC display, you
+must use the @option{-k} parameter to set the keyboard layout if you are
+not using en-us. Valid syntax for the @var{display} is
 
 @table @option
 
-- 
2.5.5




Re: [Qemu-devel] [PATCH for-2.7 2/4] virtio: decrement vq->inuse in virtqueue_discard()

2016-08-12 Thread Michael S. Tsirkin
On Fri, Aug 12, 2016 at 04:32:56PM +0100, Stefan Hajnoczi wrote:
> virtqueue_descard()

discard

> moves vq->last_avail_idx back so the element can be
> popped again.  It's necessary to decrement vq->inuse to avoid "leaking"
> the element count.
> 
> Signed-off-by: Stefan Hajnoczi 

With the correction above

Reviewed-by: Michael S. Tsirkin 


> ---
>  hw/virtio/virtio.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 4df8274..00158b6 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -268,6 +268,7 @@ void virtqueue_discard(VirtQueue *vq, const 
> VirtQueueElement *elem,
> unsigned int len)
>  {
>  vq->last_avail_idx--;
> +vq->inuse--;
>  virtqueue_unmap_sg(vq, elem, len);
>  }
>  
> -- 
> 2.7.4



Re: [Qemu-devel] [PATCH for-2.7 1/4] virtio: recalculate vq->inuse after migration

2016-08-12 Thread Michael S. Tsirkin
On Fri, Aug 12, 2016 at 04:32:55PM +0100, Stefan Hajnoczi wrote:
> The vq->inuse field is not migrated.  Many devices don't hold
> VirtQueueElements across migration so it doesn't matter that vq->inuse
> starts at 0 on the destination QEMU.
> 
> At least virtio-serial, virtio-blk, and virtio-balloon migrate while
> holding VirtQueueElements.  For these devices we need to recalculate
> vq->inuse upon load so the value is correct.
> 
> Signed-off-by: Stefan Hajnoczi 


Reviewed-by: Michael S. Tsirkin 

> ---
>  hw/virtio/virtio.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 15ee3a7..4df8274 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -1648,6 +1648,20 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f, int 
> version_id)
>  }
>  vdev->vq[i].used_idx = vring_used_idx(>vq[i]);
>  vdev->vq[i].shadow_avail_idx = vring_avail_idx(>vq[i]);
> +
> +/* Some devices migrate VirtQueueElements that have been popped
> + * from the avail ring but not yet returned to the used ring.
> + */
> +vdev->vq[i].inuse = vdev->vq[i].last_avail_idx -
> +vdev->vq[i].used_idx;
> +if (vdev->vq[i].inuse > vdev->vq[i].vring.num) {
> +error_report("VQ %d size 0x%x < last_avail_idx 0x%x - "
> + "used_idx 0x%x"
> + i, vdev->vq[i].vring.num,
> + vdev->vq[i].last_avail_idx,
> + vdev->vq[i].used_idx);
> +return -1;
> +}
>  }
>  }
>  
> -- 
> 2.7.4



Re: [Qemu-devel] [PATCH v6 2/4] vfio: VFIO driver for mediated PCI device

2016-08-12 Thread Alex Williamson
On Fri, 12 Aug 2016 23:27:01 +0530
Kirti Wankhede  wrote:

> On 8/12/2016 12:13 AM, Alex Williamson wrote:
> 
> > 
> > TBH, I don't see how providing a default implementation of
> > validate_map_request() is useful.  How many mediated devices are going
> > to want to identity map resources from the parent?  Even if they do, it
> > seems we can only support a single mediated device per parent device
> > since each will map the same parent resource offset. Let's not even try
> > to define a default.  If we get a fault and the vendor driver hasn't
> > provided a handler, send a SIGBUS.  I expect we should also allow
> > vendor drivers to fill the mapping at mmap() time rather than expecting
> > this map on fault scheme.  Maybe the mid-level driver should not even be
> > interacting with mmap() and should let the vendor driver entirely
> > determine the handling.
> >  
> 
> Should we go ahead with pass through mmap() call to vendor driver and
> let vendor driver decide what to do in mmap() call, either
> remap_pfn_range in mmap() or do fault on access and handle the fault in
> their driver. In that case we don't need to track mappings in mdev core.
> Let vendor driver do that on their own, right?

This sounds right to me, I don't think we want to impose either model
on the vendor driver.  The vendor driver owns the vfio device file
descriptor and is responsible for managing it should they expose mmap
support for regions on the file descriptor.  They either need to insert
mappings at the point where mmap() is called or setup fault handlers to
insert them on demand.  If we can provide helper functions so that each
vendor driver doesn't need to re-invent either of those, that would be
a bonus.  Thanks,

Alex



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

2016-08-12 Thread Alex Williamson
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.

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

> and
> 
> # echo "$UUID1" > /sys/devices/../mdev_destroy
> # echo "$UUID2" > /sys/devices/../mdev_destroy
> 
> Does this seems reasonable?

I've been hoping we could drop the instance numbers and create actual
unique UUIDs per mediated device for a while ;)  Thanks,

Alex



Re: [Qemu-devel] [PULL 3/3] vhost-user: Attempt to fix a race with set_mem_table.

2016-08-12 Thread Michael S. Tsirkin
On Fri, Aug 12, 2016 at 11:54:54AM -0400, Marc-André Lureau wrote:
> Hi
> 
> - Original Message -
> > On Fri, Aug 12, 2016 at 03:20:56AM -0400, Marc-André Lureau wrote:
> > > Hi
> > > 
> > > - Original Message -
> > > > sent a follow-up response to GET_FEATURES), I am now wondering if this
> > > > patch
> > > > may break existing vhost applications too ? If so, reverting it possibly
> > > > better.
> > > > What confuses me is why it doesn’t fail all the time, but only about 20%
> > > > to
> > > > 30% time as Fam reports.
> > > > 
> > > > Thoughts : Michael, Fam, MarcAndre ?
> > > 
> > > Indeed, I didn't ack that patch in the first place for that kind of
> > > reasons, so I would revert it.
> > > 
> > > thanks
> > 
> > I guess that's the safest thing to do for 2.7.
> > At least that's not any worse than 2.6.
> > I still think it's a good idea long term and test should be fixed,
> > but let's revert for now.
> > 
> 
> What about other backends that may have similar expectations from the 
> protocol.
> 
> This patch is a hack, there is no reason to have it upstream.

The reason is to avoid crashes with existing backends.

> The solution is provided with the REPLY_ACK patch.

It needs a backend update though.

But the issue is old, it's not a regression. I think we lose nothing
by pushing the work-around out until after 2.7.

-- 
MST



Re: [Qemu-devel] [V1 2/4] hw/iommu: AMD IOMMU interrupt remapping

2016-08-12 Thread David Kiarie
On Fri, Aug 12, 2016 at 11:08 PM, Valentine Sinitsyn <
valentine.sinit...@gmail.com> wrote:

> On 11.08.2016 00:42, David Kiarie wrote:
>
>> Introduce AMD IOMMU interrupt remapping and hook it onto
>
>
>> +static inline int amdvi_ir_pass(MSIMessage *src, MSIMessage *dst,
>> uint8_t bit,
>> +uint64_t dte)
>>
> The name is misleading. Actually, this function handles non-vectored
> interrupts (either passes or target aborts them). Maybe call it
> amdvi_ir_handle_non_vectored() ?
>
> +{
>> +if ((dte & (1UL << bit))) {
>> +/* passing interrupt enabled */
>> +dst->address = src->address;
>> +dst->data = src->data;
>> +} else {
>> +/* should be target aborted */
>> +return -AMDVI_TARGET_ABORT;
>> +}
>> +return 0;
>> +}
>> +
>> +static int amdvi_remap_ir_intctl(uint64_t dte, uint32_t irte,
>> + MSIMessage *src, MSIMessage *dst)
>> +{
>> +int ret = 0;
>> +
>> +switch ((dte >> AMDVI_DTE_INTCTL ) & 3UL) {
>>
> AMDVI_DTE_INTCTL_SHIFT? Yes, I should have mentioned it in a previous
> patch, sorry. Maybe also introduce macros for 3UL and 1, 2, 3 in switch
> branches below.
>
> +case 1:
>> +/* pass */
>> +memcpy(dst, src, sizeof(*dst));
>> +break;
>> +case 2:
>> +/* remap */
>> +if (irte & AMDVI_IRTE_REMAP_MASK) {
>> +/* LOCAL APIC address */
>> +dst->address = AMDVI_LOCAL_APIC_ADDR;
>> +/* destination mode */
>> +dst->address |= (((irte & AMDVI_IRTE_DM_MASK) >> 6) <<
>> +AMDVI_MSI_ADDR_DM_RSHIFT);
>> +/* RH */
>> +dst->address |= ((irte & AMDVI_IRTE_RQEOI_MASK) >> 5) <<
>> +AMDVI_MSI_ADDR_RH_RSHIFT;
>> +/* Destination ID */
>> +dst->address |= ((irte & AMDVI_IRTE_DEST_MASK) >> 8) <<
>> +AMDVI_MSI_ADDR_DEST_RSHIFT;
>> +/* construct data - vector */
>> +dst->data |= (irte & AMDVI_IRTE_VECTOR_MASK) >> 16;
>> +/* Interrupt type */
>> +dst->data |= ((irte & AMDVI_IRTE_INTTYPE_MASK) >> 2) <<
>> +AMDVI_MSI_DATA_DM_RSHIFT;
>>
> These bit operations look scary. Did you considered using bitfields or
> wrapping them in macros?


Will look at introducing macros to cover this comment and the previous one.


>
> +} else  {
>> +ret = -AMDVI_TARGET_ABORT;
>> +}
>> +break;
>> +case 0:
>> +case 3:
>>
> In fact, you should report this as event when IR == 1.
>
> +default:
>> +ret = -AMDVI_TARGET_ABORT;
>> +}
>> +return ret;
>> +}
>> +/*
>> + * We don't support guest virtual APIC so IRTE size will most likely
>> always be 4
>> + */
>> +static int amdvi_irte_get(AMDVIState *s, MSIMessage *src, uint32_t *irte,
>> +  uint64_t *dte, uint16_t devid)
>> +{
>> +uint64_t irte_root, offset = devid * AMDVI_DEVTAB_ENTRY_SIZE,
>> + irte_size = AMDVI_DEFAULT_IRTE_SIZE,
>> + ir_table_size;
>> +
>> +/* check for GASup and if it's enabled */
>> +if ((amdvi_readq(s, AMDVI_EXT_FEATURES) & AMDVI_GASUP)
>> +&& (amdvi_readq(s, AMDVI_MMIO_CONTROL) & AMDVI_GAEN)) {
>> +/* set a different IRTE size */
>> +irte_size = AMDVI_IRTE_SIZE_GASUP;
>> +}
>>
> As I said, this is likely the only place where we account for Virtual
> APIC. You don't seem to handle Virtual APIC Root in DTE, for instance.
> Maybe drop this incomplete support altogether, and print some warning here
> instead?


I'll drop everything and print a warning instead.


>
>
> +if (dma_memory_read(_space_memory, s->devtab + offset, dte,
>> +AMDVI_DEVTAB_ENTRY_SIZE)) {
>> +trace_amdvi_dte_get_fail(s->devtab, offset);
>> +return -AMDVI_DEV_TAB_HW;
>> +}
>> +
>> +irte_root = dte[2] & AMDVI_IRTEROOT_MASK;
>> +offset = (src->data & AMDVI_IRTE_INDEX_MASK) << 2;
>> +ir_table_size = pow(2, dte[2] & AMDVI_IR_TABLE_SIZE_MASK);
>>
> 1 << dte[2] & AMDVI_IR_TABLE_SIZE_MASK ?
>
>
> +/* enforce IR table size */
>> +if (offset > (ir_table_size * 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);
>> +
>> +AMDVIState *s = AMD_IOMMU_DEVICE(iommu);
>> +int ret = 0;
>> +uint64_t dte[4];
>> +uint32_t ir_enabled, irte;
>> +
>> +ret = amdvi_irte_get(s, src, , dte, sid);
>> +if (ret 

Re: [Qemu-devel] [V1 3/4] hw/acpi: report IOAPIC on IVRS

2016-08-12 Thread David Kiarie
On Fri, Aug 12, 2016 at 11:14 PM, Valentine Sinitsyn <
valentine.sinit...@gmail.com> wrote:

> On 11.08.2016 00:42, David Kiarie wrote:
>
>> 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..da602c3 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, 0x0100a000ff48, 8);
>>
> Nit: bit 3 in DTE Setting is reserved (Table 97 in the spec), while you
> set them all with 0xff.


Noted, thanks!


>
>
>
>>  build_header(linker, table_data, (void *)(table_data->data +
>> iommu_start),
>>   "IVRS", table_data->len - iommu_start, 1, NULL, NULL);
>>
>>
> Valentine
>
>


Re: [Qemu-devel] [V1 3/4] hw/acpi: report IOAPIC on IVRS

2016-08-12 Thread Valentine Sinitsyn

On 11.08.2016 00:42, David Kiarie wrote:

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..da602c3 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, 0x0100a000ff48, 8);
Nit: bit 3 in DTE Setting is reserved (Table 97 in the spec), while you 
set them all with 0xff.




 build_header(linker, table_data, (void *)(table_data->data + iommu_start),
  "IVRS", table_data->len - iommu_start, 1, NULL, NULL);



Valentine




Re: [Qemu-devel] [V1 2/4] hw/iommu: AMD IOMMU interrupt remapping

2016-08-12 Thread Valentine Sinitsyn

On 11.08.2016 00:42, David Kiarie wrote:

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

Signed-off-by: David Kiarie 
---
 hw/i386/amd_iommu.c | 226 +++-
 hw/i386/amd_iommu.h |   2 +
 2 files changed, 227 insertions(+), 1 deletion(-)

diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 5fab9aa..825159b 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -18,12 +18,14 @@
  * 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 "hw/i386/amd_iommu.h"
+#include "hw/i386/ioapic_internal.h"
 #include "hw/pci/pci_bus.h"
 #include "trace.h"

@@ -660,6 +662,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 +1228,207 @@ static IOMMUTLBEntry amdvi_translate(MemoryRegion 
*iommu, hwaddr addr,
 return ret;
 }

+static inline int amdvi_ir_pass(MSIMessage *src, MSIMessage *dst, uint8_t bit,
+uint64_t dte)
The name is misleading. Actually, this function handles non-vectored 
interrupts (either passes or target aborts them). Maybe call it 
amdvi_ir_handle_non_vectored() ?



+{
+if ((dte & (1UL << bit))) {
+/* passing interrupt enabled */
+dst->address = src->address;
+dst->data = src->data;
+} else {
+/* should be target aborted */
+return -AMDVI_TARGET_ABORT;
+}
+return 0;
+}
+
+static int amdvi_remap_ir_intctl(uint64_t dte, uint32_t irte,
+ MSIMessage *src, MSIMessage *dst)
+{
+int ret = 0;
+
+switch ((dte >> AMDVI_DTE_INTCTL ) & 3UL) {
AMDVI_DTE_INTCTL_SHIFT? Yes, I should have mentioned it in a previous 
patch, sorry. Maybe also introduce macros for 3UL and 1, 2, 3 in switch 
branches below.



+case 1:
+/* pass */
+memcpy(dst, src, sizeof(*dst));
+break;
+case 2:
+/* remap */
+if (irte & AMDVI_IRTE_REMAP_MASK) {
+/* LOCAL APIC address */
+dst->address = AMDVI_LOCAL_APIC_ADDR;
+/* destination mode */
+dst->address |= (((irte & AMDVI_IRTE_DM_MASK) >> 6) <<
+AMDVI_MSI_ADDR_DM_RSHIFT);
+/* RH */
+dst->address |= ((irte & AMDVI_IRTE_RQEOI_MASK) >> 5) <<
+AMDVI_MSI_ADDR_RH_RSHIFT;
+/* Destination ID */
+dst->address |= ((irte & AMDVI_IRTE_DEST_MASK) >> 8) <<
+AMDVI_MSI_ADDR_DEST_RSHIFT;
+/* construct data - vector */
+dst->data |= (irte & AMDVI_IRTE_VECTOR_MASK) >> 16;
+/* Interrupt type */
+dst->data |= ((irte & AMDVI_IRTE_INTTYPE_MASK) >> 2) <<
+AMDVI_MSI_DATA_DM_RSHIFT;
These bit operations look scary. Did you considered using bitfields or 
wrapping them in macros?

+} else  {
+ret = -AMDVI_TARGET_ABORT;
+}
+break;
+case 0:
+case 3:

In fact, you should report this as event when IR == 1.


+default:
+ret = -AMDVI_TARGET_ABORT;
+}
+return ret;
+}
+/*
+ * We don't support guest virtual APIC so IRTE size will most likely always be 
4
+ */
+static int amdvi_irte_get(AMDVIState *s, MSIMessage *src, uint32_t *irte,
+  uint64_t *dte, uint16_t devid)
+{
+uint64_t irte_root, offset = devid * AMDVI_DEVTAB_ENTRY_SIZE,
+ irte_size = AMDVI_DEFAULT_IRTE_SIZE,
+ ir_table_size;
+
+/* check for GASup and if it's enabled */
+if ((amdvi_readq(s, AMDVI_EXT_FEATURES) & AMDVI_GASUP)
+&& (amdvi_readq(s, AMDVI_MMIO_CONTROL) & AMDVI_GAEN)) {
+/* set a different IRTE size */
+irte_size = AMDVI_IRTE_SIZE_GASUP;
+}
As I said, this is likely the only place where we account for Virtual 
APIC. You don't seem to handle Virtual APIC Root in DTE, for instance. 
Maybe drop this incomplete support altogether, and print some warning 
here instead?



+if (dma_memory_read(_space_memory, s->devtab + offset, dte,
+AMDVI_DEVTAB_ENTRY_SIZE)) {
+trace_amdvi_dte_get_fail(s->devtab, offset);
+return -AMDVI_DEV_TAB_HW;
+}
+
+irte_root = dte[2] & AMDVI_IRTEROOT_MASK;
+offset = (src->data & AMDVI_IRTE_INDEX_MASK) << 2;
+ir_table_size = pow(2, dte[2] & AMDVI_IR_TABLE_SIZE_MASK);

1 << dte[2] & AMDVI_IR_TABLE_SIZE_MASK ?


+/* enforce IR table size */
+if (offset > (ir_table_size * irte_size)) {
+trace_amdvi_invalid_irte_entry(offset, ir_table_size);
+   

Re: [Qemu-devel] [V15 3/4] hw/i386: Introduce AMD IOMMU

2016-08-12 Thread David Kiarie
On Fri, Aug 12, 2016 at 10:10 PM, Valentine Sinitsyn <
valentine.sinit...@gmail.com> wrote:

> Hi David,
>
> On 02.08.2016 13:39, David Kiarie wrote:
>
>> Add AMD IOMMU emulaton to Qemu in addition to Intel IOMMU.
>> The IOMMU does basic translation, error checking and has a
>> minimal IOTLB implementation. This IOMMU bypassed the need
>> for target aborts by responding with IOMMU_NONE access rights
>> and exempts the region 0xfee0-0xfeef from translation
>> as it is the q35 interrupt region.
>>
>> We advertise features that are not yet implemented to please
>> the Linux IOMMU driver.
>>
>> IOTLB aims at implementing commands on real IOMMUs which is
>> essential for debugging and may not offer any performance
>> benefits
>>
>> Signed-off-by: David Kiarie 
>> ---
>> +
>> +/* 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 */
>> +#define AMDVI_MSI_DATA_DM_RSHIFT   0x8
>> +#define AMDVI_MSI_DATA_LEVEL_RSHIFT0xe
>> +#define AMDVI_MSI_DATA_TRM_RSHIFT  0xf
>> +
>> +/* offsets into MSI address */
>> +#define AMDVI_MSI_ADDR_DM_RSHIFT   0x2
>> +#define AMDVI_MSI_ADDR_RH_RSHIFT   0x3
>> +#define AMDVI_MSI_ADDR_DEST_RSHIFT 0xc
>> +
>> +#define AMDVI_LOCAL_APIC_ADDR 0xfee0
>> +
>> +/* extended feature support */
>> +#define AMDVI_EXT_FEATURES (AMDVI_FEATURE_PREFETCH | AMDVI_FEATURE_PPR |
>> \
>> +AMDVI_FEATURE_IA | AMDVI_FEATURE_GT | AMDVI_FEATURE_GA | \
>>
>

> Came across this when reviewing your IR series.
> Do you really support Guest Translation in your code? I'm also not sure if
> QEMU emulates Virtual APIC. So I'd skip the last two bits.


You mean GT and GA ? I could do a bit more research about GA but as I have
mentioned in the commit message the Linux AMD-Vi (which is the primary
target) checks for some of these features when deciding the version of this
IOMMU otherwise it defaults to IOMMU version 1.


>
> Valentine
>
>
> +AMDVI_FEATURE_HE | AMDVI_GATS_MODE | AMDVI_HATS_MODE)
>> +
>> +/* capabilities header */
>> +#define AMDVI_CAPAB_FEATURES (AMDVI_CAPAB_FLAT_EXT | \
>> +AMDVI_CAPAB_FLAG_NPCACHE | AMDVI_CAPAB_FLAG_IOTLBSUP \
>> +| AMDVI_CAPAB_ID_SEC | AMDVI_CAPAB_INIT_TYPE | \
>> +AMDVI_CAPAB_FLAG_HTTUNNEL |  AMDVI_CAPAB_EFR_SUP)
>> +
>> +/* AMDVI default address */
>> +#define AMDVI_BASE_ADDR 0xfed8
>>
>
>


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

2016-08-12 Thread 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: 1471015978-1123-1-git-send-email-stefa...@redhat.com
Subject: [Qemu-devel] [PATCH for-2.7 0/4] virtio-balloon: fix stats vq migration
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'
65e5867 virtio-balloon: fix stats vq migration
c2514f9 virtio: add virtqueue_rewind()
b743840 virtio: decrement vq->inuse in virtqueue_discard()
eb5b274 virtio: recalculate vq->inuse after migration

=== 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
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 ucontext
coroutine poolyes
GlusterFS support no
Archipelago support no
gcov  gcov
gcov enabled  no
TPM support   yes
libssh2 support   no
TPM passthrough   yes
QOM debugging yes
vhdx  no
lzo support   no
snappy supportno
bzip2 support no
NUMA host support no
tcmalloc support  no
jemalloc support  no
avx2 optimization no
  GEN   x86_64-softmmu/config-devices.mak.tmp
  GEN   aarch64-softmmu/config-devices.mak.tmp
  GEN   config-host.h
  GEN   qemu-options.def

Re: [Qemu-devel] [V15 3/4] hw/i386: Introduce AMD IOMMU

2016-08-12 Thread Valentine Sinitsyn

On 13.08.2016 00:40, David Kiarie wrote:



On Fri, Aug 12, 2016 at 10:10 PM, Valentine Sinitsyn
> wrote:

Hi David,

On 02.08.2016 13:39, David Kiarie wrote:

Add AMD IOMMU emulaton to Qemu in addition to Intel IOMMU.
The IOMMU does basic translation, error checking and has a
minimal IOTLB implementation. This IOMMU bypassed the need
for target aborts by responding with IOMMU_NONE access rights
and exempts the region 0xfee0-0xfeef from translation
as it is the q35 interrupt region.

We advertise features that are not yet implemented to please
the Linux IOMMU driver.

IOTLB aims at implementing commands on real IOMMUs which is
essential for debugging and may not offer any performance
benefits

Signed-off-by: David Kiarie >
---
+
+/* 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 */
+#define AMDVI_MSI_DATA_DM_RSHIFT   0x8
+#define AMDVI_MSI_DATA_LEVEL_RSHIFT0xe
+#define AMDVI_MSI_DATA_TRM_RSHIFT  0xf
+
+/* offsets into MSI address */
+#define AMDVI_MSI_ADDR_DM_RSHIFT   0x2
+#define AMDVI_MSI_ADDR_RH_RSHIFT   0x3
+#define AMDVI_MSI_ADDR_DEST_RSHIFT 0xc
+
+#define AMDVI_LOCAL_APIC_ADDR 0xfee0
+
+/* extended feature support */
+#define AMDVI_EXT_FEATURES (AMDVI_FEATURE_PREFETCH |
AMDVI_FEATURE_PPR | \
+AMDVI_FEATURE_IA | AMDVI_FEATURE_GT | AMDVI_FEATURE_GA | \



Came across this when reviewing your IR series.
Do you really support Guest Translation in your code? I'm also not
sure if QEMU emulates Virtual APIC. So I'd skip the last two bits.


You mean GT and GA ? I could do a bit more research about GA but as I
have mentioned in the commit message the Linux AMD-Vi (which is the
primary target) checks for some of these features when deciding the
version of this IOMMU otherwise it defaults to IOMMU version 1.

True. Ignore this comment then.

Valentine




Valentine


+AMDVI_FEATURE_HE | AMDVI_GATS_MODE | AMDVI_HATS_MODE)
+
+/* capabilities header */
+#define AMDVI_CAPAB_FEATURES (AMDVI_CAPAB_FLAT_EXT | \
+AMDVI_CAPAB_FLAG_NPCACHE | AMDVI_CAPAB_FLAG_IOTLBSUP \
+| AMDVI_CAPAB_ID_SEC | AMDVI_CAPAB_INIT_TYPE | \
+AMDVI_CAPAB_FLAG_HTTUNNEL |  AMDVI_CAPAB_EFR_SUP)
+
+/* AMDVI default address */
+#define AMDVI_BASE_ADDR 0xfed8








Re: [Qemu-devel] [PATCH for 2.7] ppc: parse cpu features once

2016-08-12 Thread Eduardo Habkost
On Wed, Aug 10, 2016 at 09:08:01PM +0200, Cédric Le Goater wrote:
> From: Greg Kurz 
> 
> Considering that features are converted to global properties and
> global properties are automatically applied to every new instance
> of created CPU (at object_new() time), there is no point in
> parsing cpu_model string every time a CPU created. So move
> parsing outside CPU creation loop and do it only once.
> 
> Parsing also should be done before any CPU is created so that
> features would affect the first CPU a well.
> 
> This patch does that for all PowerPC machine types.

This line needs to be removed from the commit message.

> 
> It is based on previous work from Bharata:
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg07564.html
> 
> Signed-off-by: Greg Kurz 
> [clg: only kept the fix for the spapr platform. support for other
>   platform will be added in 2.8 ]
> Signed-off-by: Cédric Le Goater 

Reviewed-by: Eduardo Habkost 

Thanks!

-- 
Eduardo



Re: [Qemu-devel] [V1 1/4] hw/iommu: Prepare for AMD IOMMU interrupt remapping

2016-08-12 Thread Valentine Sinitsyn

On 11.08.2016 00:42, David Kiarie wrote:

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

Signed-off-by: David Kiarie 
---
 hw/i386/amd_iommu.h  | 72 
 hw/i386/trace-events |  7 +
 2 files changed, 79 insertions(+)

diff --git a/hw/i386/amd_iommu.h b/hw/i386/amd_iommu.h
index 5d0b91d..2a7f19e 100644
--- a/hw/i386/amd_iommu.h
+++ b/hw/i386/amd_iommu.h
@@ -177,6 +177,78 @@
 #define AMDVI_IOTLB_MAX_SIZE 1024
 #define AMDVI_DEVID_SHIFT36

+/* interrupt types */
+#define AMDVI_MT_FIXED  0x0
+#define AMDVI_MT_ARBIT  0x1
+#define AMDVI_MT_SMI0x2
+#define AMDVI_MT_NMI0x3
+#define AMDVI_MT_INIT   0x4
+#define AMDVI_MT_EXTINT 0x6
+#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
+
+/* interrupt destination mode */
+#define AMDVI_IRDEST_MODE_MASK 0x2
+
+/* select MSI data 10:0 bits */
+#define AMDVI_IRTE_INDEX_MASK 0x7ff
+
+/* 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

I suggest adding _SHIFT prefix, to make the meaning clearer.


+
+/* interrupt data valid */
+#define AMDVI_IR_VALID  (1UL << 0)
+
+/* interrupt root table mask */
+#define AMDVI_IRTEROOT_MASK 0xc0
+
+/* default IRTE size */
+#define AMDVI_DEFAULT_IRTE_SIZE 0x4
+
+/* IRTE size with GASup enabled */
+#define AMDVI_IRTE_SIZE_GASUP   0x10
We don't have Virtual APIC, and perhaps this is not needed (see comments 
in the next patch).



+
+#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 */
+#define AMDVI_MSI_DATA_DM_RSHIFT   0x8
+#define AMDVI_MSI_DATA_LEVEL_RSHIFT0xe
+#define AMDVI_MSI_DATA_TRM_RSHIFT  0xf
+
+/* offsets into MSI address */
+#define AMDVI_MSI_ADDR_DM_RSHIFT   0x2
+#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
So you decided not to keep these as a single 
AMDVI_SOUTHBRIDGE_IOAPIC_ID, or similar?


Valentine


+
+#define AMDVI_LOCAL_APIC_ADDR 0xfee0
+
 /* extended feature support */
 #define AMDVI_EXT_FEATURES (AMDVI_FEATURE_PREFETCH | AMDVI_FEATURE_PPR | \
 AMDVI_FEATURE_IA | AMDVI_FEATURE_GT | AMDVI_FEATURE_GA | \
diff --git a/hw/i386/trace-events b/hw/i386/trace-events
index 592de3a..5c12c10 100644
--- a/hw/i386/trace-events
+++ b/hw/i386/trace-events
@@ -42,3 +42,10 @@ amdvi_mode_invalid(unsigned level, uint64_t addr)"error: 
translation level 0x%"P
 amdvi_page_fault(uint64_t addr) "error: page fault accessing guest physical address 
0x%"PRIx64
 amdvi_iotlb_hit(uint16_t bus, uint16_t slot, uint16_t func, uint64_t addr, uint64_t txaddr) 
"hit iotlb devid %02x:%02x.%x gpa 0x%"PRIx64 " hpa 0x%"PRIx64
 amdvi_translation_result(uint16_t bus, uint16_t slot, uint16_t func, uint64_t addr, uint64_t 
txaddr) "devid: %02x:%02x.%x gpa 0x%"PRIx64 " hpa 0x%"PRIx64
+amdvi_irte_get_fail(uint64_t addr, uint64_t offset) "couldn't access device table entry 
0x%"PRIx64" + offset 0x%"PRIx64
+amdvi_invalid_irte_entry(uint16_t devid, uint64_t offset) "devid %x requested IRTE offset 
0x%"PRIx64" Outside IR table range"
+amdvi_ir_request(uint32_t data, uint64_t addr, uint16_t sid) "IR request data 0x%"PRIx32" 
address 0x%"PRIx64" SID %x"
+amdvi_ir_remap(uint32_t data, uint64_t addr, uint16_t sid) "IR remap data 0x%"PRIx32" address 
0x%"PRIx64" SID %x"
+amdvi_ir_target_abort(uint32_t data, uint64_t addr, uint16_t sid) "IR target abort data 
0x%"PRIx32" address 0x%"PRIx64" SID %x"
+amdvi_ir_write_fail(uint64_t addr, uint32_t data) "fail to write to addr 0x%"PRIx64 
" value 0x%"PRIx32
+amdvi_ir_read_fail(uint64_t addr) " fail to read from addr 0x%"PRIx64






Re: [Qemu-devel] [V15 3/4] hw/i386: Introduce AMD IOMMU

2016-08-12 Thread Valentine Sinitsyn

Hi David,

On 02.08.2016 13:39, David Kiarie wrote:

Add AMD IOMMU emulaton to Qemu in addition to Intel IOMMU.
The IOMMU does basic translation, error checking and has a
minimal IOTLB implementation. This IOMMU bypassed the need
for target aborts by responding with IOMMU_NONE access rights
and exempts the region 0xfee0-0xfeef from translation
as it is the q35 interrupt region.

We advertise features that are not yet implemented to please
the Linux IOMMU driver.

IOTLB aims at implementing commands on real IOMMUs which is
essential for debugging and may not offer any performance
benefits

Signed-off-by: David Kiarie 
---
 hw/i386/Makefile.objs |1 +
 hw/i386/amd_iommu.c   | 1397 +
 hw/i386/amd_iommu.h   |  390 ++
 hw/i386/trace-events  |7 +
 4 files changed, 1795 insertions(+)
 create mode 100644 hw/i386/amd_iommu.c
 create mode 100644 hw/i386/amd_iommu.h

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 90e94ff..909ead6 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,6 +3,7 @@ obj-y += multiboot.o
 obj-y += pc.o pc_piix.o pc_q35.o
 obj-y += pc_sysfw.o
 obj-y += x86-iommu.o intel_iommu.o
+obj-y += amd_iommu.o
 obj-$(CONFIG_XEN) += ../xenpv/ xen/

 obj-y += kvmvapic.o
diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
new file mode 100644
index 000..7b64dd7
--- /dev/null
+++ b/hw/i386/amd_iommu.c
@@ -0,0 +1,1397 @@
+/*
+ * QEMU emulation of AMD IOMMU (AMD-Vi)
+ *
+ * Copyright (C) 2011 Eduard - Gabriel Munteanu
+ * Copyright (C) 2015 David Kiarie, 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ * 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 "hw/i386/amd_iommu.h"
+#include "hw/pci/pci_bus.h"
+#include "trace.h"
+
+/* used AMD-Vi MMIO registers */
+const char *amdvi_mmio_low[] = {
+"AMDVI_MMIO_DEVTAB_BASE",
+"AMDVI_MMIO_CMDBUF_BASE",
+"AMDVI_MMIO_EVTLOG_BASE",
+"AMDVI_MMIO_CONTROL",
+"AMDVI_MMIO_EXCL_BASE",
+"AMDVI_MMIO_EXCL_LIMIT",
+"AMDVI_MMIO_EXT_FEATURES",
+"AMDVI_MMIO_PPR_BASE",
+"UNHANDLED"
+};
+const char *amdvi_mmio_high[] = {
+"AMDVI_MMIO_COMMAND_HEAD",
+"AMDVI_MMIO_COMMAND_TAIL",
+"AMDVI_MMIO_EVTLOG_HEAD",
+"AMDVI_MMIO_EVTLOG_TAIL",
+"AMDVI_MMIO_STATUS",
+"AMDVI_MMIO_PPR_HEAD",
+"AMDVI_MMIO_PPR_TAIL",
+"UNHANDLED"
+};
+typedef struct AMDVIAddressSpace {
+uint8_t bus_num;/* bus number   */
+uint8_t devfn;  /* device function  */
+AMDVIState *iommu_state;/* AMDVI - one per machine  */
+MemoryRegion iommu; /* Device's address translation region  */
+MemoryRegion iommu_ir;  /* Device's interrupt remapping region  */
+AddressSpace as;/* device's corresponding address space */
+} AMDVIAddressSpace;
+
+/* AMDVI cache entry */
+typedef struct AMDVIIOTLBEntry {
+uint64_t gfn;   /* guest frame number  */
+uint16_t domid; /* assigned domain id  */
+uint16_t devid; /* device owning entry */
+uint64_t perms; /* access permissions  */
+uint64_t translated_addr;   /* translated address  */
+uint64_t page_mask; /* physical page size  */
+} AMDVIIOTLBEntry;
+
+/* serialize IOMMU command processing */
+typedef struct QEMU_PACKED {
+#ifdef HOST_WORDS_BIGENDIAN
+uint64_t type:4;   /* command type   */
+uint64_t reserved:8;
+uint64_t store_addr:49;/* addr to write  */
+uint64_t completion_flush:1;   /* allow more executions  */
+uint64_t completion_int:1; /* set MMIOWAITINT*/
+uint64_t completion_store:1;   /* write data to address  */
+#else
+uint64_t completion_store:1;
+uint64_t completion_int:1;
+uint64_t completion_flush:1;
+uint64_t store_addr:49;
+uint64_t reserved:8;
+uint64_t type:4;
+#endif /* __BIG_ENDIAN_BITFIELD */
+uint64_t store_data;   /* data to write  */
+} CMDCompletionWait;
+
+/* invalidate internal caches for devid */
+typedef struct QEMU_PACKED {
+#ifdef HOST_WORDS_BIGENDIAN
+uint64_t devid;/* device to 

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

2016-08-12 Thread Kirti Wankhede


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

and

# echo "$UUID1" > /sys/devices/../mdev_destroy
# echo "$UUID2" > /sys/devices/../mdev_destroy

Does this seems reasonable?

Thanks,
Kirti



[Qemu-devel] [PATCH v2 16/17] target-ppc: improve stxvw4x implementation

2016-08-12 Thread Nikunj A Dadhania
Manipulate data and store 8bytes instead of 4bytes.

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate/vsx-impl.inc.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/target-ppc/translate/vsx-impl.inc.c 
b/target-ppc/translate/vsx-impl.inc.c
index caa6660..f2fc5f9 100644
--- a/target-ppc/translate/vsx-impl.inc.c
+++ b/target-ppc/translate/vsx-impl.inc.c
@@ -205,7 +205,8 @@ static void gen_stxvd2x(DisasContext *ctx)
 
 static void gen_stxvw4x(DisasContext *ctx)
 {
-TCGv_i64 tmp;
+TCGv_i64 xsh = cpu_vsrh(xS(ctx->opcode));
+TCGv_i64 xsl = cpu_vsrl(xS(ctx->opcode));
 TCGv EA;
 if (unlikely(!ctx->vsx_enabled)) {
 gen_exception(ctx, POWERPC_EXCP_VSXU);
@@ -214,21 +215,19 @@ static void gen_stxvw4x(DisasContext *ctx)
 gen_set_access_type(ctx, ACCESS_INT);
 EA = tcg_temp_new();
 gen_addr_reg_index(ctx, EA);
-tmp = tcg_temp_new_i64();
-
-tcg_gen_shri_i64(tmp, cpu_vsrh(xS(ctx->opcode)), 32);
-gen_qemu_st32_i64(ctx, tmp, EA);
-tcg_gen_addi_tl(EA, EA, 4);
-gen_qemu_st32_i64(ctx, cpu_vsrh(xS(ctx->opcode)), EA);
-
-tcg_gen_shri_i64(tmp, cpu_vsrl(xS(ctx->opcode)), 32);
-tcg_gen_addi_tl(EA, EA, 4);
-gen_qemu_st32_i64(ctx, tmp, EA);
-tcg_gen_addi_tl(EA, EA, 4);
-gen_qemu_st32_i64(ctx, cpu_vsrl(xS(ctx->opcode)), EA);
 
+if (ctx->le_mode) {
+tcg_gen_qemu_st_i64(xsh, EA, ctx->mem_idx, MO_BEQ);
+tcg_gen_addi_tl(EA, EA, 8);
+tcg_gen_qemu_st_i64(xsl, EA, ctx->mem_idx, MO_BEQ);
+} else {
+gen_helper_bswap32x2(xsh, xsh);
+tcg_gen_qemu_st_i64(xsh, EA, ctx->mem_idx, MO_LEQ);
+tcg_gen_addi_tl(EA, EA, 8);
+gen_helper_bswap32x2(xsl, xsl);
+tcg_gen_qemu_st_i64(xsl, EA, ctx->mem_idx, MO_LEQ);
+}
 tcg_temp_free(EA);
-tcg_temp_free_i64(tmp);
 }
 
 #define MV_VSRW(name, tcgop1, tcgop2, target, source)   \
-- 
2.7.4




[Qemu-devel] [PATCH v2 17/17] target-ppc: add stxvb16x and stxvh8x

2016-08-12 Thread Nikunj A Dadhania
stxvb16x: Store VSX Vector Byte*16
stxvh8x:  Store VSX Vector Halfword*8

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate/vsx-impl.inc.c | 55 +
 target-ppc/translate/vsx-ops.inc.c  |  2 ++
 2 files changed, 57 insertions(+)

diff --git a/target-ppc/translate/vsx-impl.inc.c 
b/target-ppc/translate/vsx-impl.inc.c
index f2fc5f9..20afe3b 100644
--- a/target-ppc/translate/vsx-impl.inc.c
+++ b/target-ppc/translate/vsx-impl.inc.c
@@ -165,6 +165,61 @@ static void gen_lxvh8x(DisasContext *ctx)
 tcg_temp_free(EA);
 }
 
+static void gen_stxvb16x(DisasContext *ctx)
+{
+TCGv_i64 xsh = cpu_vsrh(xS(ctx->opcode));
+TCGv_i64 xsl = cpu_vsrl(xS(ctx->opcode));
+TCGv EA;
+
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+gen_set_access_type(ctx, ACCESS_INT);
+EA = tcg_temp_new();
+gen_addr_reg_index(ctx, EA);
+
+if (ctx->le_mode) {
+tcg_gen_qemu_st_i64(xsh, EA, ctx->mem_idx, MO_BEQ);
+tcg_gen_addi_tl(EA, EA, 8);
+tcg_gen_qemu_st_i64(xsl, EA, ctx->mem_idx, MO_BEQ);
+} else {
+gen_helper_bswap32x2(xsh, xsh);
+tcg_gen_qemu_st_i64(xsh, EA, ctx->mem_idx, MO_LEQ);
+tcg_gen_addi_tl(EA, EA, 8);
+gen_helper_bswap32x2(xsl, xsl);
+tcg_gen_qemu_st_i64(xsl, EA, ctx->mem_idx, MO_LEQ);
+}
+tcg_temp_free(EA);
+}
+
+static void gen_stxvh8x(DisasContext *ctx)
+{
+TCGv_i64 xsh = cpu_vsrh(xS(ctx->opcode));
+TCGv_i64 xsl = cpu_vsrl(xS(ctx->opcode));
+TCGv EA;
+
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+gen_set_access_type(ctx, ACCESS_INT);
+EA = tcg_temp_new();
+gen_addr_reg_index(ctx, EA);
+if (ctx->le_mode) {
+tcg_gen_qemu_st_i64(xsh, EA, ctx->mem_idx, MO_BEQ);
+tcg_gen_addi_tl(EA, EA, 8);
+tcg_gen_qemu_st_i64(xsl, EA, ctx->mem_idx, MO_BEQ);
+} else {
+gen_helper_bswap32x2(xsh, xsh);
+tcg_gen_qemu_st_i64(xsh, EA, ctx->mem_idx, MO_LEQ);
+tcg_gen_addi_tl(EA, EA, 8);
+gen_helper_bswap32x2(xsl, xsl);
+tcg_gen_qemu_st_i64(xsl, EA, ctx->mem_idx, MO_LEQ);
+}
+tcg_temp_free(EA);
+}
+
 #define VSX_STORE_SCALAR(name, operation) \
 static void gen_##name(DisasContext *ctx) \
 { \
diff --git a/target-ppc/translate/vsx-ops.inc.c 
b/target-ppc/translate/vsx-ops.inc.c
index 598b349..f5afa0f 100644
--- a/target-ppc/translate/vsx-ops.inc.c
+++ b/target-ppc/translate/vsx-ops.inc.c
@@ -17,6 +17,8 @@ GEN_HANDLER_E(stxsiwx, 0x1F, 0xC, 0x04, 0, PPC_NONE, 
PPC2_VSX207),
 GEN_HANDLER_E(stxsspx, 0x1F, 0xC, 0x14, 0, PPC_NONE, PPC2_VSX207),
 GEN_HANDLER_E(stxvd2x, 0x1F, 0xC, 0x1E, 0, PPC_NONE, PPC2_VSX),
 GEN_HANDLER_E(stxvw4x, 0x1F, 0xC, 0x1C, 0, PPC_NONE, PPC2_VSX),
+GEN_HANDLER_E(stxvh8x, 0x1F, 0x0C, 0x1D, 0, PPC_NONE,  PPC2_ISA300),
+GEN_HANDLER_E(stxvb16x, 0x1F, 0x0C, 0x1F, 0, PPC_NONE, PPC2_ISA300),
 
 GEN_HANDLER_E(mfvsrwz, 0x1F, 0x13, 0x03, 0xF800, PPC_NONE, PPC2_VSX207),
 GEN_HANDLER_E(mtvsrwa, 0x1F, 0x13, 0x06, 0xF800, PPC_NONE, PPC2_VSX207),
-- 
2.7.4




[Qemu-devel] [PATCH v2 10/17] target-ppc: add xxspltib instruction

2016-08-12 Thread Nikunj A Dadhania
xxspltib: VSX Vector Splat Immediate Byte

Copy the immediate byte in each byte of target VSR

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c  |  2 ++
 target-ppc/translate/vsx-impl.inc.c | 20 
 target-ppc/translate/vsx-ops.inc.c  |  5 +
 3 files changed, 27 insertions(+)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index bba196c..89a4b37 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -589,6 +589,8 @@ EXTRACT_HELPER(DM, 8, 2);
 EXTRACT_HELPER(UIM, 16, 2);
 EXTRACT_HELPER(SHW, 8, 2);
 EXTRACT_HELPER(SP, 19, 2);
+EXTRACT_HELPER(IMM8, 11, 8);
+
 /*/
 /* PowerPC instructions table*/
 
diff --git a/target-ppc/translate/vsx-impl.inc.c 
b/target-ppc/translate/vsx-impl.inc.c
index 99cabb2..67f5621 100644
--- a/target-ppc/translate/vsx-impl.inc.c
+++ b/target-ppc/translate/vsx-impl.inc.c
@@ -647,6 +647,26 @@ static void gen_xxspltw(DisasContext *ctx)
 tcg_temp_free_i64(b2);
 }
 
+#define pattern(x) (((x) & 0xff) * (~(uint64_t)0 / 0xff))
+
+static void gen_xxspltib(DisasContext *ctx)
+{
+unsigned char uim8 = IMM8(ctx->opcode);
+if (xS(ctx->opcode) < 32) {
+if (unlikely(!ctx->altivec_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VPU);
+return;
+}
+} else {
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+}
+tcg_gen_movi_i64(cpu_vsrh(xT(ctx->opcode)), pattern(uim8));
+tcg_gen_movi_i64(cpu_vsrl(xT(ctx->opcode)), pattern(uim8));
+}
+
 static void gen_xxsldwi(DisasContext *ctx)
 {
 TCGv_i64 xth, xtl;
diff --git a/target-ppc/translate/vsx-ops.inc.c 
b/target-ppc/translate/vsx-ops.inc.c
index 8b9da65..62a6251 100644
--- a/target-ppc/translate/vsx-ops.inc.c
+++ b/target-ppc/translate/vsx-ops.inc.c
@@ -20,6 +20,10 @@ GEN_HANDLER_E(mfvsrd, 0x1F, 0x13, 0x01, 0xF800, 
PPC_NONE, PPC2_VSX207),
 GEN_HANDLER_E(mtvsrd, 0x1F, 0x13, 0x05, 0xF800, PPC_NONE, PPC2_VSX207),
 #endif
 
+#define GEN_XX1FORM(name, opc2, opc3, fl2)  \
+GEN_HANDLER2_E(name, #name, 0x3C, opc2 | 0, opc3, 0, PPC_NONE, fl2), \
+GEN_HANDLER2_E(name, #name, 0x3C, opc2 | 1, opc3, 0, PPC_NONE, fl2)
+
 #define GEN_XX2FORM(name, opc2, opc3, fl2)   \
 GEN_HANDLER2_E(name, #name, 0x3C, opc2 | 0, opc3, 0, PPC_NONE, fl2), \
 GEN_HANDLER2_E(name, #name, 0x3C, opc2 | 1, opc3, 0, PPC_NONE, fl2)
@@ -222,6 +226,7 @@ VSX_LOGICAL(xxlorc, 0x8, 0x15, PPC2_VSX207),
 GEN_XX3FORM(xxmrghw, 0x08, 0x02, PPC2_VSX),
 GEN_XX3FORM(xxmrglw, 0x08, 0x06, PPC2_VSX),
 GEN_XX2FORM(xxspltw, 0x08, 0x0A, PPC2_VSX),
+GEN_XX1FORM(xxspltib, 0x08, 0x0B, PPC2_ISA300),
 GEN_XX3FORM_DM(xxsldwi, 0x08, 0x00),
 
 #define GEN_XXSEL_ROW(opc3) \
-- 
2.7.4




[Qemu-devel] [PATCH v2 15/17] target-ppc: add lxvb16x and lxvh8x

2016-08-12 Thread Nikunj A Dadhania
lxvb16x: Load VSX Vector Byte*16
lxvh8x:  Load VSX Vector Halfword*8

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/helper.h |  1 +
 target-ppc/mem_helper.c |  6 
 target-ppc/translate/vsx-impl.inc.c | 57 +
 target-ppc/translate/vsx-ops.inc.c  |  2 ++
 4 files changed, 66 insertions(+)

diff --git a/target-ppc/helper.h b/target-ppc/helper.h
index ce214f7..ab80c34 100644
--- a/target-ppc/helper.h
+++ b/target-ppc/helper.h
@@ -289,6 +289,7 @@ DEF_HELPER_3(lvebx, void, env, avr, tl)
 DEF_HELPER_3(lvehx, void, env, avr, tl)
 DEF_HELPER_3(lvewx, void, env, avr, tl)
 DEF_HELPER_1(bswap32x2, i64, i64)
+DEF_HELPER_1(bswap16x4, i64, i64)
 DEF_HELPER_3(stvebx, void, env, avr, tl)
 DEF_HELPER_3(stvehx, void, env, avr, tl)
 DEF_HELPER_3(stvewx, void, env, avr, tl)
diff --git a/target-ppc/mem_helper.c b/target-ppc/mem_helper.c
index 070dff6..09d552f 100644
--- a/target-ppc/mem_helper.c
+++ b/target-ppc/mem_helper.c
@@ -359,6 +359,12 @@ uint64_t helper_bswap32x2(uint64_t x)
 return deposit64((x >> 32), 32, 32, (x));
 }
 
+uint64_t helper_bswap16x4(uint64_t x)
+{
+uint64_t m = 0x00ff00ff00ff00ffull;
+return ((x & m) << 8) | ((x >> 8) & m);
+}
+
 #undef HI_IDX
 #undef LO_IDX
 
diff --git a/target-ppc/translate/vsx-impl.inc.c 
b/target-ppc/translate/vsx-impl.inc.c
index e3374df..caa6660 100644
--- a/target-ppc/translate/vsx-impl.inc.c
+++ b/target-ppc/translate/vsx-impl.inc.c
@@ -108,6 +108,63 @@ static void gen_lxvw4x(DisasContext *ctx)
 tcg_temp_free(EA);
 }
 
+static void gen_lxvb16x(DisasContext *ctx)
+{
+TCGv EA;
+TCGv_i64 xth = cpu_vsrh(xT(ctx->opcode));
+TCGv_i64 xtl = cpu_vsrl(xT(ctx->opcode));
+
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+gen_set_access_type(ctx, ACCESS_INT);
+EA = tcg_temp_new();
+gen_addr_reg_index(ctx, EA);
+if (ctx->le_mode) {
+tcg_gen_qemu_ld_i64(xth, EA, ctx->mem_idx, MO_BEQ);
+tcg_gen_addi_tl(EA, EA, 8);
+tcg_gen_qemu_ld_i64(xtl, EA, ctx->mem_idx, MO_BEQ);
+} else {
+tcg_gen_qemu_ld_i64(xth, EA, ctx->mem_idx, MO_LEQ);
+gen_helper_bswap32x2(xth, xth);
+tcg_gen_addi_tl(EA, EA, 8);
+tcg_gen_qemu_ld_i64(xtl, EA, ctx->mem_idx, MO_LEQ);
+gen_helper_bswap32x2(xtl, xtl);
+}
+tcg_temp_free(EA);
+}
+
+static void gen_lxvh8x(DisasContext *ctx)
+{
+TCGv EA;
+TCGv_i64 xth = cpu_vsrh(xT(ctx->opcode));
+TCGv_i64 xtl = cpu_vsrl(xT(ctx->opcode));
+
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+gen_set_access_type(ctx, ACCESS_INT);
+EA = tcg_temp_new();
+gen_addr_reg_index(ctx, EA);
+
+if (ctx->le_mode) {
+tcg_gen_qemu_ld_i64(xth, EA, ctx->mem_idx, MO_BEQ);
+gen_helper_bswap16x4(xth, xth);
+tcg_gen_addi_tl(EA, EA, 8);
+tcg_gen_qemu_ld_i64(xtl, EA, ctx->mem_idx, MO_BEQ);
+gen_helper_bswap16x4(xtl, xtl);
+} else {
+tcg_gen_qemu_ld_i64(xth, EA, ctx->mem_idx, MO_LEQ);
+gen_helper_bswap32x2(xth, xth);
+tcg_gen_addi_tl(EA, EA, 8);
+tcg_gen_qemu_ld_i64(xtl, EA, ctx->mem_idx, MO_LEQ);
+gen_helper_bswap32x2(xtl, xtl);
+}
+tcg_temp_free(EA);
+}
+
 #define VSX_STORE_SCALAR(name, operation) \
 static void gen_##name(DisasContext *ctx) \
 { \
diff --git a/target-ppc/translate/vsx-ops.inc.c 
b/target-ppc/translate/vsx-ops.inc.c
index 414b73b..598b349 100644
--- a/target-ppc/translate/vsx-ops.inc.c
+++ b/target-ppc/translate/vsx-ops.inc.c
@@ -7,6 +7,8 @@ GEN_HANDLER_E(lxsspx, 0x1F, 0x0C, 0x10, 0, PPC_NONE, 
PPC2_VSX207),
 GEN_HANDLER_E(lxvd2x, 0x1F, 0x0C, 0x1A, 0, PPC_NONE, PPC2_VSX),
 GEN_HANDLER_E(lxvdsx, 0x1F, 0x0C, 0x0A, 0, PPC_NONE, PPC2_VSX),
 GEN_HANDLER_E(lxvw4x, 0x1F, 0x0C, 0x18, 0, PPC_NONE, PPC2_VSX),
+GEN_HANDLER_E(lxvh8x, 0x1F, 0x0C, 0x19, 0, PPC_NONE,  PPC2_ISA300),
+GEN_HANDLER_E(lxvb16x, 0x1F, 0x0C, 0x1B, 0, PPC_NONE, PPC2_ISA300),
 
 GEN_HANDLER_E(stxsdx, 0x1F, 0xC, 0x16, 0, PPC_NONE, PPC2_VSX),
 GEN_HANDLER_E(stxsibx, 0x1F, 0xD, 0x1C, 0, PPC_NONE, PPC2_ISA300),
-- 
2.7.4




[Qemu-devel] [PATCH v2 02/17] target-ppc: convert ld64 to use new macro

2016-08-12 Thread Nikunj A Dadhania
Use macro for ld64 as well, this changes the function signature from
gen_qemu_ld64 => gen_qemu_ld64_i64. Replace this at all the call sites.

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c  | 39 +++---
 target-ppc/translate/fp-impl.inc.c  | 42 ++---
 target-ppc/translate/spe-impl.inc.c |  2 +-
 target-ppc/translate/vmx-impl.inc.c | 12 +--
 target-ppc/translate/vsx-impl.inc.c |  8 +++
 5 files changed, 49 insertions(+), 54 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 30d548a..42f403a 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -2486,12 +2486,7 @@ static void glue(gen_qemu_, glue(ldop, 
_i64))(DisasContext *ctx,\
 
 GEN_QEMU_LOAD_64(ld32u, DEF_MEMOP(MO_UL))
 GEN_QEMU_LOAD_64(ld32s, DEF_MEMOP(MO_SL))
-
-static inline void gen_qemu_ld64(DisasContext *ctx, TCGv_i64 arg1, TCGv arg2)
-{
-TCGMemOp op = MO_Q | ctx->default_tcg_memop_mask;
-tcg_gen_qemu_ld_i64(arg1, arg2, ctx->mem_idx, op);
-}
+GEN_QEMU_LOAD_64(ld64,  DEF_MEMOP(MO_Q))
 
 static inline void gen_qemu_st8(DisasContext *ctx, TCGv arg1, TCGv arg2)
 {
@@ -2610,12 +2605,12 @@ GEN_LDUX(lwa, ld32s, 0x15, 0x0B, PPC_64B);
 /* lwax */
 GEN_LDX(lwa, ld32s, 0x15, 0x0A, PPC_64B);
 /* ldux */
-GEN_LDUX(ld, ld64, 0x15, 0x01, PPC_64B);
+GEN_LDUX(ld, ld64_i64, 0x15, 0x01, PPC_64B);
 /* ldx */
-GEN_LDX(ld, ld64, 0x15, 0x00, PPC_64B);
+GEN_LDX(ld, ld64_i64, 0x15, 0x00, PPC_64B);
 
 /* CI load/store variants */
-GEN_LDX_HVRM(ldcix, ld64, 0x15, 0x1b, PPC_CILDST)
+GEN_LDX_HVRM(ldcix, ld64_i64, 0x15, 0x1b, PPC_CILDST)
 GEN_LDX_HVRM(lwzcix, ld32u, 0x15, 0x15, PPC_CILDST)
 GEN_LDX_HVRM(lhzcix, ld16u, 0x15, 0x19, PPC_CILDST)
 GEN_LDX_HVRM(lbzcix, ld8u, 0x15, 0x1a, PPC_CILDST)
@@ -2638,7 +2633,7 @@ static void gen_ld(DisasContext *ctx)
 gen_qemu_ld32s(ctx, cpu_gpr[rD(ctx->opcode)], EA);
 } else {
 /* ld - ldu */
-gen_qemu_ld64(ctx, cpu_gpr[rD(ctx->opcode)], EA);
+gen_qemu_ld64_i64(ctx, cpu_gpr[rD(ctx->opcode)], EA);
 }
 if (Rc(ctx->opcode))
 tcg_gen_mov_tl(cpu_gpr[rA(ctx->opcode)], EA);
@@ -2675,16 +2670,16 @@ static void gen_lq(DisasContext *ctx)
 EA = tcg_temp_new();
 gen_addr_imm_index(ctx, EA, 0x0F);
 
-/* We only need to swap high and low halves. gen_qemu_ld64 does necessary
-   64-bit byteswap already. */
+/* We only need to swap high and low halves. gen_qemu_ld64_i64 does
+   necessary 64-bit byteswap already. */
 if (unlikely(ctx->le_mode)) {
-gen_qemu_ld64(ctx, cpu_gpr[rd+1], EA);
+gen_qemu_ld64_i64(ctx, cpu_gpr[rd + 1], EA);
 gen_addr_add(ctx, EA, EA, 8);
-gen_qemu_ld64(ctx, cpu_gpr[rd], EA);
+gen_qemu_ld64_i64(ctx, cpu_gpr[rd], EA);
 } else {
-gen_qemu_ld64(ctx, cpu_gpr[rd], EA);
+gen_qemu_ld64_i64(ctx, cpu_gpr[rd], EA);
 gen_addr_add(ctx, EA, EA, 8);
-gen_qemu_ld64(ctx, cpu_gpr[rd+1], EA);
+gen_qemu_ld64_i64(ctx, cpu_gpr[rd + 1], EA);
 }
 tcg_temp_free(EA);
 }
@@ -3182,7 +3177,7 @@ STCX(stwcx_, 4);
 
 #if defined(TARGET_PPC64)
 /* ldarx */
-LARX(ldarx, 8, ld64);
+LARX(ldarx, 8, ld64_i64);
 
 /* lqarx */
 static void gen_lqarx(DisasContext *ctx)
@@ -3208,11 +3203,11 @@ static void gen_lqarx(DisasContext *ctx)
 gpr1 = cpu_gpr[rd];
 gpr2 = cpu_gpr[rd+1];
 }
-gen_qemu_ld64(ctx, gpr1, EA);
+gen_qemu_ld64_i64(ctx, gpr1, EA);
 tcg_gen_mov_tl(cpu_reserve, EA);
 
 gen_addr_add(ctx, EA, EA, 8);
-gen_qemu_ld64(ctx, gpr2, EA);
+gen_qemu_ld64_i64(ctx, gpr2, EA);
 
 tcg_gen_st_tl(gpr1, cpu_env, offsetof(CPUPPCState, reserve_val));
 tcg_gen_st_tl(gpr2, cpu_env, offsetof(CPUPPCState, reserve_val2));
@@ -6596,12 +6591,12 @@ GEN_LDS(lwz, ld32u, 0x00, PPC_INTEGER)
 #if defined(TARGET_PPC64)
 GEN_LDUX(lwa, ld32s, 0x15, 0x0B, PPC_64B)
 GEN_LDX(lwa, ld32s, 0x15, 0x0A, PPC_64B)
-GEN_LDUX(ld, ld64, 0x15, 0x01, PPC_64B)
-GEN_LDX(ld, ld64, 0x15, 0x00, PPC_64B)
+GEN_LDUX(ld, ld64_i64, 0x15, 0x01, PPC_64B)
+GEN_LDX(ld, ld64_i64, 0x15, 0x00, PPC_64B)
 GEN_LDX_E(ldbr, ld64ur, 0x14, 0x10, PPC_NONE, PPC2_DBRX, CHK_NONE)
 
 /* HV/P7 and later only */
-GEN_LDX_HVRM(ldcix, ld64, 0x15, 0x1b, PPC_CILDST)
+GEN_LDX_HVRM(ldcix, ld64_i64, 0x15, 0x1b, PPC_CILDST)
 GEN_LDX_HVRM(lwzcix, ld32u, 0x15, 0x18, PPC_CILDST)
 GEN_LDX_HVRM(lhzcix, ld16u, 0x15, 0x19, PPC_CILDST)
 GEN_LDX_HVRM(lbzcix, ld8u, 0x15, 0x1a, PPC_CILDST)
diff --git a/target-ppc/translate/fp-impl.inc.c 
b/target-ppc/translate/fp-impl.inc.c
index 9ba9289..53b7fc7 100644
--- a/target-ppc/translate/fp-impl.inc.c
+++ b/target-ppc/translate/fp-impl.inc.c
@@ -672,7 +672,7 @@ static inline void gen_qemu_ld32fs(DisasContext *ctx, 
TCGv_i64 arg1, TCGv arg2)
 }
 
  /* lfd lfdu lfdux lfdx */
-GEN_LDFS(lfd, ld64, 0x12, PPC_FLOAT);
+GEN_LDFS(lfd, ld64_i64, 0x12, PPC_FLOAT);
  /* lfs lfsu lfsux lfsx */
 GEN_LDFS(lfs, ld32fs, 0x10, PPC_FLOAT);
 

[Qemu-devel] [PATCH v2 12/17] target-ppc: add lxsi[bw]zx instruction

2016-08-12 Thread Nikunj A Dadhania
lxsibzx - Load VSX Scalar as Integer Byte & Zero Indexed
lxsihzx - Load VSX Scalar as Integer Halfword & Zero Indexed

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c  | 2 ++
 target-ppc/translate/vsx-impl.inc.c | 2 ++
 target-ppc/translate/vsx-ops.inc.c  | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 2e5116e..e72b8d7 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -2507,6 +2507,8 @@ static void glue(gen_qemu_, glue(ldop, 
_i64))(DisasContext *ctx,\
 tcg_gen_qemu_ld_i64(val, addr, ctx->mem_idx, op);   \
 }
 
+GEN_QEMU_LOAD_64(ld8u,  DEF_MEMOP(MO_UB))
+GEN_QEMU_LOAD_64(ld16u, DEF_MEMOP(MO_UW))
 GEN_QEMU_LOAD_64(ld32u, DEF_MEMOP(MO_UL))
 GEN_QEMU_LOAD_64(ld32s, DEF_MEMOP(MO_SL))
 GEN_QEMU_LOAD_64(ld64,  DEF_MEMOP(MO_Q))
diff --git a/target-ppc/translate/vsx-impl.inc.c 
b/target-ppc/translate/vsx-impl.inc.c
index 67f5621..888f2e4 100644
--- a/target-ppc/translate/vsx-impl.inc.c
+++ b/target-ppc/translate/vsx-impl.inc.c
@@ -36,6 +36,8 @@ static void gen_##name(DisasContext *ctx) 
\
 
 VSX_LOAD_SCALAR(lxsdx, ld64_i64)
 VSX_LOAD_SCALAR(lxsiwax, ld32s_i64)
+VSX_LOAD_SCALAR(lxsibzx, ld8u_i64)
+VSX_LOAD_SCALAR(lxsihzx, ld16u_i64)
 VSX_LOAD_SCALAR(lxsiwzx, ld32u_i64)
 VSX_LOAD_SCALAR(lxsspx, ld32fs)
 
diff --git a/target-ppc/translate/vsx-ops.inc.c 
b/target-ppc/translate/vsx-ops.inc.c
index 62a6251..4cd742c 100644
--- a/target-ppc/translate/vsx-ops.inc.c
+++ b/target-ppc/translate/vsx-ops.inc.c
@@ -1,6 +1,8 @@
 GEN_HANDLER_E(lxsdx, 0x1F, 0x0C, 0x12, 0, PPC_NONE, PPC2_VSX),
 GEN_HANDLER_E(lxsiwax, 0x1F, 0x0C, 0x02, 0, PPC_NONE, PPC2_VSX207),
 GEN_HANDLER_E(lxsiwzx, 0x1F, 0x0C, 0x00, 0, PPC_NONE, PPC2_VSX207),
+GEN_HANDLER_E(lxsibzx, 0x1F, 0x0D, 0x18, 0, PPC_NONE, PPC2_ISA300),
+GEN_HANDLER_E(lxsihzx, 0x1F, 0x0D, 0x19, 0, PPC_NONE, PPC2_ISA300),
 GEN_HANDLER_E(lxsspx, 0x1F, 0x0C, 0x10, 0, PPC_NONE, PPC2_VSX207),
 GEN_HANDLER_E(lxvd2x, 0x1F, 0x0C, 0x1A, 0, PPC_NONE, PPC2_VSX),
 GEN_HANDLER_E(lxvdsx, 0x1F, 0x0C, 0x0A, 0, PPC_NONE, PPC2_VSX),
-- 
2.7.4




[Qemu-devel] [PATCH v2 13/17] target-ppc: add stxsi[bh]x instruction

2016-08-12 Thread Nikunj A Dadhania
stxsibx - Store VSX Scalar as Integer Byte Indexed
stxsihx - Store VSX Scalar as Integer Halfword Indexed

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c  | 2 ++
 target-ppc/translate/vsx-impl.inc.c | 3 +++
 target-ppc/translate/vsx-ops.inc.c  | 2 ++
 3 files changed, 7 insertions(+)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index e72b8d7..4a882b3 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -2540,6 +2540,8 @@ static void glue(gen_qemu_, glue(stop, 
_i64))(DisasContext *ctx,  \
 tcg_gen_qemu_st_i64(val, addr, ctx->mem_idx, op); \
 }
 
+GEN_QEMU_STORE_64(st8,  DEF_MEMOP(MO_UB))
+GEN_QEMU_STORE_64(st16, DEF_MEMOP(MO_UW))
 GEN_QEMU_STORE_64(st32, DEF_MEMOP(MO_UL))
 GEN_QEMU_STORE_64(st64, DEF_MEMOP(MO_Q))
 
diff --git a/target-ppc/translate/vsx-impl.inc.c 
b/target-ppc/translate/vsx-impl.inc.c
index 888f2e4..eee6052 100644
--- a/target-ppc/translate/vsx-impl.inc.c
+++ b/target-ppc/translate/vsx-impl.inc.c
@@ -118,6 +118,9 @@ static void gen_##name(DisasContext *ctx)   
  \
 }
 
 VSX_STORE_SCALAR(stxsdx, st64_i64)
+
+VSX_STORE_SCALAR(stxsibx, st8_i64)
+VSX_STORE_SCALAR(stxsihx, st16_i64)
 VSX_STORE_SCALAR(stxsiwx, st32_i64)
 VSX_STORE_SCALAR(stxsspx, st32fs)
 
diff --git a/target-ppc/translate/vsx-ops.inc.c 
b/target-ppc/translate/vsx-ops.inc.c
index 4cd742c..414b73b 100644
--- a/target-ppc/translate/vsx-ops.inc.c
+++ b/target-ppc/translate/vsx-ops.inc.c
@@ -9,6 +9,8 @@ GEN_HANDLER_E(lxvdsx, 0x1F, 0x0C, 0x0A, 0, PPC_NONE, PPC2_VSX),
 GEN_HANDLER_E(lxvw4x, 0x1F, 0x0C, 0x18, 0, PPC_NONE, PPC2_VSX),
 
 GEN_HANDLER_E(stxsdx, 0x1F, 0xC, 0x16, 0, PPC_NONE, PPC2_VSX),
+GEN_HANDLER_E(stxsibx, 0x1F, 0xD, 0x1C, 0, PPC_NONE, PPC2_ISA300),
+GEN_HANDLER_E(stxsihx, 0x1F, 0xD, 0x1D, 0, PPC_NONE, PPC2_ISA300),
 GEN_HANDLER_E(stxsiwx, 0x1F, 0xC, 0x04, 0, PPC_NONE, PPC2_VSX207),
 GEN_HANDLER_E(stxsspx, 0x1F, 0xC, 0x14, 0, PPC_NONE, PPC2_VSX207),
 GEN_HANDLER_E(stxvd2x, 0x1F, 0xC, 0x1E, 0, PPC_NONE, PPC2_VSX),
-- 
2.7.4




[Qemu-devel] [PATCH v2 05/17] target-ppc: convert st64 to use new macro

2016-08-12 Thread Nikunj A Dadhania
Use macro for ld64 as well, this changes the function signature from
gen_qemu_st64 => gen_qemu_st64_i64. Replace this at all the call sites.

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c  | 37 ++--
 target-ppc/translate/fp-impl.inc.c  | 42 ++---
 target-ppc/translate/fp-ops.inc.c   |  2 +-
 target-ppc/translate/spe-impl.inc.c |  2 +-
 target-ppc/translate/vmx-impl.inc.c | 12 +--
 target-ppc/translate/vsx-impl.inc.c |  6 +++---
 6 files changed, 48 insertions(+), 53 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index a893c91..bd16681 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -2517,12 +2517,7 @@ static void glue(gen_qemu_, glue(stop, 
_i64))(DisasContext *ctx,  \
 }
 
 GEN_QEMU_STORE_64(st32, DEF_MEMOP(MO_UL))
-
-static inline void gen_qemu_st64(DisasContext *ctx, TCGv_i64 arg1, TCGv arg2)
-{
-TCGMemOp op = MO_Q | ctx->default_tcg_memop_mask;
-tcg_gen_qemu_st_i64(arg1, arg2, ctx->mem_idx, op);
-}
+GEN_QEMU_STORE_64(st64, DEF_MEMOP(MO_Q))
 
 #define GEN_LD(name, ldop, opc, type) \
 static void glue(gen_, name)(DisasContext *ctx)
   \
@@ -2767,9 +2762,9 @@ GEN_STS(sth, st16, 0x0C, PPC_INTEGER);
 /* stw stwu stwux stwx */
 GEN_STS(stw, st32, 0x04, PPC_INTEGER);
 #if defined(TARGET_PPC64)
-GEN_STUX(std, st64, 0x15, 0x05, PPC_64B);
-GEN_STX(std, st64, 0x15, 0x04, PPC_64B);
-GEN_STX_HVRM(stdcix, st64, 0x15, 0x1f, PPC_CILDST)
+GEN_STUX(std, st64_i64, 0x15, 0x05, PPC_64B);
+GEN_STX(std, st64_i64, 0x15, 0x04, PPC_64B);
+GEN_STX_HVRM(stdcix, st64_i64, 0x15, 0x1f, PPC_CILDST)
 GEN_STX_HVRM(stwcix, st32, 0x15, 0x1c, PPC_CILDST)
 GEN_STX_HVRM(sthcix, st16, 0x15, 0x1d, PPC_CILDST)
 GEN_STX_HVRM(stbcix, st8, 0x15, 0x1e, PPC_CILDST)
@@ -2806,16 +2801,16 @@ static void gen_std(DisasContext *ctx)
 EA = tcg_temp_new();
 gen_addr_imm_index(ctx, EA, 0x03);
 
-/* We only need to swap high and low halves. gen_qemu_st64 does
+/* We only need to swap high and low halves. gen_qemu_st64_i64 does
necessary 64-bit byteswap already. */
 if (unlikely(ctx->le_mode)) {
-gen_qemu_st64(ctx, cpu_gpr[rs+1], EA);
+gen_qemu_st64_i64(ctx, cpu_gpr[rs + 1], EA);
 gen_addr_add(ctx, EA, EA, 8);
-gen_qemu_st64(ctx, cpu_gpr[rs], EA);
+gen_qemu_st64_i64(ctx, cpu_gpr[rs], EA);
 } else {
-gen_qemu_st64(ctx, cpu_gpr[rs], EA);
+gen_qemu_st64_i64(ctx, cpu_gpr[rs], EA);
 gen_addr_add(ctx, EA, EA, 8);
-gen_qemu_st64(ctx, cpu_gpr[rs+1], EA);
+gen_qemu_st64_i64(ctx, cpu_gpr[rs + 1], EA);
 }
 tcg_temp_free(EA);
 } else {
@@ -2829,7 +2824,7 @@ static void gen_std(DisasContext *ctx)
 gen_set_access_type(ctx, ACCESS_INT);
 EA = tcg_temp_new();
 gen_addr_imm_index(ctx, EA, 0x03);
-gen_qemu_st64(ctx, cpu_gpr[rs], EA);
+gen_qemu_st64_i64(ctx, cpu_gpr[rs], EA);
 if (Rc(ctx->opcode))
 tcg_gen_mov_tl(cpu_gpr[rA(ctx->opcode)], EA);
 tcg_temp_free(EA);
@@ -3111,7 +3106,7 @@ static void gen_conditional_store(DisasContext *ctx, TCGv 
EA,
 tcg_gen_ori_i32(cpu_crf[0], cpu_crf[0], 1 << CRF_EQ);
 #if defined(TARGET_PPC64)
 if (size == 8) {
-gen_qemu_st64(ctx, cpu_gpr[reg], EA);
+gen_qemu_st64_i64(ctx, cpu_gpr[reg], EA);
 } else
 #endif
 if (size == 4) {
@@ -3128,10 +3123,10 @@ static void gen_conditional_store(DisasContext *ctx, 
TCGv EA,
 gpr1 = cpu_gpr[reg];
 gpr2 = cpu_gpr[reg+1];
 }
-gen_qemu_st64(ctx, gpr1, EA);
+gen_qemu_st64_i64(ctx, gpr1, EA);
 EA8 = tcg_temp_local_new();
 gen_addr_add(ctx, EA8, EA, 8);
-gen_qemu_st64(ctx, gpr2, EA8);
+gen_qemu_st64_i64(ctx, gpr2, EA8);
 tcg_temp_free(EA8);
 #endif
 } else {
@@ -6617,10 +6612,10 @@ GEN_STS(stb, st8, 0x06, PPC_INTEGER)
 GEN_STS(sth, st16, 0x0C, PPC_INTEGER)
 GEN_STS(stw, st32, 0x04, PPC_INTEGER)
 #if defined(TARGET_PPC64)
-GEN_STUX(std, st64, 0x15, 0x05, PPC_64B)
-GEN_STX(std, st64, 0x15, 0x04, PPC_64B)
+GEN_STUX(std, st64_i64, 0x15, 0x05, PPC_64B)
+GEN_STX(std, st64_i64, 0x15, 0x04, PPC_64B)
 GEN_STX_E(stdbr, st64r, 0x14, 0x14, PPC_NONE, PPC2_DBRX, CHK_NONE)
-GEN_STX_HVRM(stdcix, st64, 0x15, 0x1f, PPC_CILDST)
+GEN_STX_HVRM(stdcix, st64_i64, 0x15, 0x1f, PPC_CILDST)
 GEN_STX_HVRM(stwcix, st32, 0x15, 0x1c, PPC_CILDST)
 GEN_STX_HVRM(sthcix, st16, 0x15, 0x1d, PPC_CILDST)
 GEN_STX_HVRM(stbcix, st8, 0x15, 0x1e, PPC_CILDST)
diff --git a/target-ppc/translate/fp-impl.inc.c 
b/target-ppc/translate/fp-impl.inc.c
index 53b7fc7..872af7b 100644
--- a/target-ppc/translate/fp-impl.inc.c
+++ b/target-ppc/translate/fp-impl.inc.c
@@ -848,7 +848,7 @@ static inline void gen_qemu_st32fs(DisasContext 

[Qemu-devel] [PATCH v2 11/17] target-ppc: implement darn instruction

2016-08-12 Thread Nikunj A Dadhania
From: Ravi Bangoria 

darn: Deliver A Random Number

Currently return invalid random number for all the case. This needs
proper algorithm to provide cryptographically suitable random data.
Reading from /dev/random can block and that is not an expected behaviour
while the cpu instruction is getting executed. Moreover, /dev/random
would only work for linux-user

Signed-off-by: Ravi Bangoria 
Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/helper.h |  2 ++
 target-ppc/int_helper.c | 16 
 target-ppc/translate.c  | 18 ++
 3 files changed, 36 insertions(+)

diff --git a/target-ppc/helper.h b/target-ppc/helper.h
index dcf3f95..695a2db 100644
--- a/target-ppc/helper.h
+++ b/target-ppc/helper.h
@@ -50,6 +50,8 @@ DEF_HELPER_FLAGS_1(cnttzd, TCG_CALL_NO_RWG_SE, tl, tl)
 DEF_HELPER_FLAGS_1(popcntd, TCG_CALL_NO_RWG_SE, tl, tl)
 DEF_HELPER_FLAGS_2(bpermd, TCG_CALL_NO_RWG_SE, i64, i64, i64)
 DEF_HELPER_3(srad, tl, env, tl, tl)
+DEF_HELPER_0(darn32, tl)
+DEF_HELPER_0(darn64, tl)
 #endif
 
 DEF_HELPER_FLAGS_1(cntlsw32, TCG_CALL_NO_RWG_SE, i32, i32)
diff --git a/target-ppc/int_helper.c b/target-ppc/int_helper.c
index 552b2e0..ca33add 100644
--- a/target-ppc/int_helper.c
+++ b/target-ppc/int_helper.c
@@ -182,6 +182,22 @@ target_ulong helper_cnttzd(target_ulong t)
 {
 return ctz64(t);
 }
+
+/* Return invalid random number.
+ *
+ * FIXME: Add rng backend or other mechanism to get cryptographically suitable
+ * random number
+ */
+target_ulong helper_darn32(void)
+{
+return -1;
+}
+
+target_ulong helper_darn64(void)
+{
+return -1;
+}
+
 #endif
 
 #if defined(TARGET_PPC64)
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 89a4b37..2e5116e 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -526,6 +526,8 @@ EXTRACT_HELPER(FPW, 16, 1);
 
 /* addpcis */
 EXTRACT_HELPER_DXFORM(DX, 10, 6, 6, 5, 16, 1, 1, 0, 0)
+/* darn */
+EXTRACT_HELPER(L, 16, 2);
 
 /***Jump target decoding   ***/
 /* Immediate address */
@@ -1893,6 +1895,21 @@ static void gen_cnttzd(DisasContext *ctx)
 gen_set_Rc0(ctx, cpu_gpr[rA(ctx->opcode)]);
 }
 }
+
+/* darn */
+static void gen_darn(DisasContext *ctx)
+{
+int l = L(ctx->opcode);
+
+if (l == 0) {
+gen_helper_darn32(cpu_gpr[rD(ctx->opcode)]);
+} else if (l <= 2) {
+/* Return 64-bit random for both CRN and RRN */
+gen_helper_darn64(cpu_gpr[rD(ctx->opcode)]);
+} else {
+tcg_gen_movi_i64(cpu_gpr[rD(ctx->opcode)], -1);
+}
+}
 #endif
 
 /*** Integer rotate***/
@@ -6207,6 +6224,7 @@ GEN_HANDLER_E(prtyw, 0x1F, 0x1A, 0x04, 0xF801, 
PPC_NONE, PPC2_ISA205),
 GEN_HANDLER(popcntd, 0x1F, 0x1A, 0x0F, 0xF801, PPC_POPCNTWD),
 GEN_HANDLER(cntlzd, 0x1F, 0x1A, 0x01, 0x, PPC_64B),
 GEN_HANDLER_E(cnttzd, 0x1F, 0x1A, 0x11, 0x, PPC_NONE, PPC2_ISA300),
+GEN_HANDLER_E(darn, 0x1F, 0x13, 0x17, 0x001CF801, PPC_NONE, PPC2_ISA300),
 GEN_HANDLER_E(prtyd, 0x1F, 0x1A, 0x05, 0xF801, PPC_NONE, PPC2_ISA205),
 GEN_HANDLER_E(bpermd, 0x1F, 0x1C, 0x07, 0x0001, PPC_NONE, 
PPC2_PERM_ISA206),
 #endif
-- 
2.7.4




[Qemu-devel] [PATCH v2 07/17] target-ppc: consolidate load with reservation

2016-08-12 Thread Nikunj A Dadhania
Use tcg_gen_qemu_ld in the load with reservation instructions.

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 21092d0..87857f7 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -3047,28 +3047,30 @@ static void gen_isync(DisasContext *ctx)
 gen_stop_exception(ctx);
 }
 
-#define LARX(name, len, loadop)  \
+#define MEMOP_GET_SIZE(x)  (1 << ((x) & MO_SIZE))
+
+#define LARX(name, memop)\
 static void gen_##name(DisasContext *ctx)\
 {\
 TCGv t0; \
 TCGv gpr = cpu_gpr[rD(ctx->opcode)]; \
+int len = MEMOP_GET_SIZE(memop); \
 gen_set_access_type(ctx, ACCESS_RES);\
 t0 = tcg_temp_local_new();   \
 gen_addr_reg_index(ctx, t0); \
 if ((len) > 1) { \
 gen_check_align(ctx, t0, (len)-1);   \
 }\
-gen_qemu_##loadop(ctx, gpr, t0); \
+tcg_gen_qemu_ld_tl(gpr, t0, ctx->mem_idx, memop);\
 tcg_gen_mov_tl(cpu_reserve, t0); \
 tcg_gen_st_tl(gpr, cpu_env, offsetof(CPUPPCState, reserve_val)); \
 tcg_temp_free(t0);   \
 }
 
 /* lwarx */
-LARX(lbarx, 1, ld8u);
-LARX(lharx, 2, ld16u);
-LARX(lwarx, 4, ld32u);
-
+LARX(lbarx, DEF_MEMOP(MO_UB))
+LARX(lharx, DEF_MEMOP(MO_UW))
+LARX(lwarx, DEF_MEMOP(MO_UL))
 
 #if defined(CONFIG_USER_ONLY)
 static void gen_conditional_store(DisasContext *ctx, TCGv EA,
@@ -3150,7 +3152,7 @@ STCX(stwcx_, 4);
 
 #if defined(TARGET_PPC64)
 /* ldarx */
-LARX(ldarx, 8, ld64_i64);
+LARX(ldarx, DEF_MEMOP(MO_Q))
 
 /* lqarx */
 static void gen_lqarx(DisasContext *ctx)
@@ -3176,15 +3178,13 @@ static void gen_lqarx(DisasContext *ctx)
 gpr1 = cpu_gpr[rd];
 gpr2 = cpu_gpr[rd+1];
 }
-gen_qemu_ld64_i64(ctx, gpr1, EA);
+tcg_gen_qemu_ld_i64(gpr1, EA, ctx->mem_idx, DEF_MEMOP(MO_Q));
 tcg_gen_mov_tl(cpu_reserve, EA);
-
 gen_addr_add(ctx, EA, EA, 8);
-gen_qemu_ld64_i64(ctx, gpr2, EA);
+tcg_gen_qemu_ld_i64(gpr2, EA, ctx->mem_idx, DEF_MEMOP(MO_Q));
 
 tcg_gen_st_tl(gpr1, cpu_env, offsetof(CPUPPCState, reserve_val));
 tcg_gen_st_tl(gpr2, cpu_env, offsetof(CPUPPCState, reserve_val2));
-
 tcg_temp_free(EA);
 }
 
-- 
2.7.4




[Qemu-devel] [PATCH v2 08/17] target-ppc: move out stqcx impementation

2016-08-12 Thread Nikunj A Dadhania
Being a 16byte operation, qemu_ld/st still does not support this. Move
this out so other store operation can use qemu_ld/st in the following
patch. Also, convert it to two MO_Q operations for stqcx.

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c | 69 ++
 1 file changed, 47 insertions(+), 22 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 87857f7..f3d2c4e 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -3103,22 +3103,6 @@ static void gen_conditional_store(DisasContext *ctx, 
TCGv EA,
 gen_qemu_st32(ctx, cpu_gpr[reg], EA);
 } else if (size == 2) {
 gen_qemu_st16(ctx, cpu_gpr[reg], EA);
-#if defined(TARGET_PPC64)
-} else if (size == 16) {
-TCGv gpr1, gpr2 , EA8;
-if (unlikely(ctx->le_mode)) {
-gpr1 = cpu_gpr[reg+1];
-gpr2 = cpu_gpr[reg];
-} else {
-gpr1 = cpu_gpr[reg];
-gpr2 = cpu_gpr[reg+1];
-}
-gen_qemu_st64_i64(ctx, gpr1, EA);
-EA8 = tcg_temp_local_new();
-gen_addr_add(ctx, EA8, EA, 8);
-gen_qemu_st64_i64(ctx, gpr2, EA8);
-tcg_temp_free(EA8);
-#endif
 } else {
 gen_qemu_st8(ctx, cpu_gpr[reg], EA);
 }
@@ -3131,11 +3115,6 @@ static void gen_conditional_store(DisasContext *ctx, 
TCGv EA,
 static void gen_##name(DisasContext *ctx) \
 { \
 TCGv t0;  \
-if (unlikely((len == 16) && (rD(ctx->opcode) & 1))) { \
-gen_inval_exception(ctx,  \
-POWERPC_EXCP_INVAL_INVAL);\
-return;   \
-} \
 gen_set_access_type(ctx, ACCESS_RES); \
 t0 = tcg_temp_local_new();\
 gen_addr_reg_index(ctx, t0);  \
@@ -3188,9 +3167,55 @@ static void gen_lqarx(DisasContext *ctx)
 tcg_temp_free(EA);
 }
 
+/* stqcx. */
+static void gen_stqcx_(DisasContext *ctx)
+{
+TCGv EA;
+int reg = rS(ctx->opcode);
+int len = 16;
+#if !defined(CONFIG_USER_ONLY)
+TCGLabel *l1;
+TCGv gpr1, gpr2;
+#endif
+
+if (unlikely((rD(ctx->opcode) & 1))) {
+gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
+return;
+}
+gen_set_access_type(ctx, ACCESS_RES);
+EA = tcg_temp_local_new();
+gen_addr_reg_index(ctx, EA);
+if (len > 1) {
+gen_check_align(ctx, EA, (len) - 1);
+}
+
+#if defined(CONFIG_USER_ONLY)
+gen_conditional_store(ctx, EA, reg, 16);
+#else
+tcg_gen_trunc_tl_i32(cpu_crf[0], cpu_so);
+l1 = gen_new_label();
+tcg_gen_brcond_tl(TCG_COND_NE, EA, cpu_reserve, l1);
+tcg_gen_ori_i32(cpu_crf[0], cpu_crf[0], 1 << CRF_EQ);
+
+if (unlikely(ctx->le_mode)) {
+gpr1 = cpu_gpr[reg + 1];
+gpr2 = cpu_gpr[reg];
+} else {
+gpr1 = cpu_gpr[reg];
+gpr2 = cpu_gpr[reg + 1];
+}
+tcg_gen_qemu_st_tl(gpr1, EA, ctx->mem_idx, DEF_MEMOP(MO_Q));
+gen_addr_add(ctx, EA, EA, 8);
+tcg_gen_qemu_st_tl(gpr2, EA, ctx->mem_idx, DEF_MEMOP(MO_Q));
+
+gen_set_label(l1);
+tcg_gen_movi_tl(cpu_reserve, -1);
+#endif
+tcg_temp_free(EA);
+}
+
 /* stdcx. */
 STCX(stdcx_, 8);
-STCX(stqcx_, 16);
 #endif /* defined(TARGET_PPC64) */
 
 /* sync */
-- 
2.7.4




[Qemu-devel] [PATCH v2 09/17] target-ppc: consolidate store conditional

2016-08-12 Thread Nikunj A Dadhania
Use tcg_gen_qemu_st store conditional instructions.

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c | 58 +-
 1 file changed, 24 insertions(+), 34 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index f3d2c4e..bba196c 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -3074,19 +3074,19 @@ LARX(lwarx, DEF_MEMOP(MO_UL))
 
 #if defined(CONFIG_USER_ONLY)
 static void gen_conditional_store(DisasContext *ctx, TCGv EA,
-  int reg, int size)
+  int reg, int memop)
 {
 TCGv t0 = tcg_temp_new();
 
 tcg_gen_st_tl(EA, cpu_env, offsetof(CPUPPCState, reserve_ea));
-tcg_gen_movi_tl(t0, (size << 5) | reg);
+tcg_gen_movi_tl(t0, (MEMOP_GET_SIZE(memop) << 5) | reg);
 tcg_gen_st_tl(t0, cpu_env, offsetof(CPUPPCState, reserve_info));
 tcg_temp_free(t0);
 gen_exception_err(ctx, POWERPC_EXCP_STCX, 0);
 }
 #else
 static void gen_conditional_store(DisasContext *ctx, TCGv EA,
-  int reg, int size)
+  int reg, int memop)
 {
 TCGLabel *l1;
 
@@ -3094,44 +3094,36 @@ static void gen_conditional_store(DisasContext *ctx, 
TCGv EA,
 l1 = gen_new_label();
 tcg_gen_brcond_tl(TCG_COND_NE, EA, cpu_reserve, l1);
 tcg_gen_ori_i32(cpu_crf[0], cpu_crf[0], 1 << CRF_EQ);
-#if defined(TARGET_PPC64)
-if (size == 8) {
-gen_qemu_st64_i64(ctx, cpu_gpr[reg], EA);
-} else
-#endif
-if (size == 4) {
-gen_qemu_st32(ctx, cpu_gpr[reg], EA);
-} else if (size == 2) {
-gen_qemu_st16(ctx, cpu_gpr[reg], EA);
-} else {
-gen_qemu_st8(ctx, cpu_gpr[reg], EA);
-}
+tcg_gen_qemu_st_tl(cpu_gpr[reg], EA, ctx->mem_idx, memop);
 gen_set_label(l1);
 tcg_gen_movi_tl(cpu_reserve, -1);
 }
 #endif
 
-#define STCX(name, len)   \
-static void gen_##name(DisasContext *ctx) \
-{ \
-TCGv t0;  \
-gen_set_access_type(ctx, ACCESS_RES); \
-t0 = tcg_temp_local_new();\
-gen_addr_reg_index(ctx, t0);  \
-if (len > 1) {\
-gen_check_align(ctx, t0, (len)-1);\
-} \
-gen_conditional_store(ctx, t0, rS(ctx->opcode), len); \
-tcg_temp_free(t0);\
-}
-
-STCX(stbcx_, 1);
-STCX(sthcx_, 2);
-STCX(stwcx_, 4);
+#define STCX(name, memop)   \
+static void gen_##name(DisasContext *ctx)   \
+{   \
+TCGv t0;\
+int len = MEMOP_GET_SIZE(memop);\
+gen_set_access_type(ctx, ACCESS_RES);   \
+t0 = tcg_temp_local_new();  \
+gen_addr_reg_index(ctx, t0);\
+if (len > 1) {  \
+gen_check_align(ctx, t0, (len) - 1);\
+}   \
+gen_conditional_store(ctx, t0, rS(ctx->opcode), memop); \
+tcg_temp_free(t0);  \
+}
+
+STCX(stbcx_, DEF_MEMOP(MO_UB))
+STCX(sthcx_, DEF_MEMOP(MO_UW))
+STCX(stwcx_, DEF_MEMOP(MO_UL))
 
 #if defined(TARGET_PPC64)
 /* ldarx */
 LARX(ldarx, DEF_MEMOP(MO_Q))
+/* stdcx. */
+STCX(stdcx_, DEF_MEMOP(MO_Q))
 
 /* lqarx */
 static void gen_lqarx(DisasContext *ctx)
@@ -3214,8 +3206,6 @@ static void gen_stqcx_(DisasContext *ctx)
 tcg_temp_free(EA);
 }
 
-/* stdcx. */
-STCX(stdcx_, 8);
 #endif /* defined(TARGET_PPC64) */
 
 /* sync */
-- 
2.7.4




[Qemu-devel] [PATCH v2 06/17] target-ppc: convert st[16, 32, 64]r to use new macro

2016-08-12 Thread Nikunj A Dadhania
Make byte-swap routines use the common GEN_QEMU_LOAD macro

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c | 32 ++--
 1 file changed, 10 insertions(+), 22 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index bd16681..21092d0 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -2508,6 +2508,9 @@ GEN_QEMU_STORE_TL(st8,  DEF_MEMOP(MO_UB))
 GEN_QEMU_STORE_TL(st16, DEF_MEMOP(MO_UW))
 GEN_QEMU_STORE_TL(st32, DEF_MEMOP(MO_UL))
 
+GEN_QEMU_STORE_TL(st16r, BSWAP_MEMOP(MO_UW))
+GEN_QEMU_STORE_TL(st32r, BSWAP_MEMOP(MO_UL))
+
 #define GEN_QEMU_STORE_64(stop, op)   \
 static void glue(gen_qemu_, glue(stop, _i64))(DisasContext *ctx,  \
   TCGv_i64 val,   \
@@ -2519,6 +2522,10 @@ static void glue(gen_qemu_, glue(stop, 
_i64))(DisasContext *ctx,  \
 GEN_QEMU_STORE_64(st32, DEF_MEMOP(MO_UL))
 GEN_QEMU_STORE_64(st64, DEF_MEMOP(MO_Q))
 
+#if defined(TARGET_PPC64)
+GEN_QEMU_STORE_64(st64r, BSWAP_MEMOP(MO_Q))
+#endif
+
 #define GEN_LD(name, ldop, opc, type) \
 static void glue(gen_, name)(DisasContext *ctx)
   \
 { \
@@ -2842,34 +2849,15 @@ GEN_LDX(lwbr, ld32ur, 0x16, 0x10, PPC_INTEGER);
 #if defined(TARGET_PPC64)
 /* ldbrx */
 GEN_LDX_E(ldbr, ld64ur_i64, 0x14, 0x10, PPC_NONE, PPC2_DBRX, CHK_NONE);
+/* stdbrx */
+GEN_STX_E(stdbr, st64r_i64, 0x14, 0x14, PPC_NONE, PPC2_DBRX, CHK_NONE);
 #endif  /* TARGET_PPC64 */
 
 /* sthbrx */
-static inline void gen_qemu_st16r(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_UW | (ctx->default_tcg_memop_mask ^ MO_BSWAP);
-tcg_gen_qemu_st_tl(arg1, arg2, ctx->mem_idx, op);
-}
 GEN_STX(sthbr, st16r, 0x16, 0x1C, PPC_INTEGER);
-
 /* stwbrx */
-static inline void gen_qemu_st32r(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_UL | (ctx->default_tcg_memop_mask ^ MO_BSWAP);
-tcg_gen_qemu_st_tl(arg1, arg2, ctx->mem_idx, op);
-}
 GEN_STX(stwbr, st32r, 0x16, 0x14, PPC_INTEGER);
 
-#if defined(TARGET_PPC64)
-/* stdbrx */
-static inline void gen_qemu_st64r(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_Q | (ctx->default_tcg_memop_mask ^ MO_BSWAP);
-tcg_gen_qemu_st_i64(arg1, arg2, ctx->mem_idx, op);
-}
-GEN_STX_E(stdbr, st64r, 0x14, 0x14, PPC_NONE, PPC2_DBRX, CHK_NONE);
-#endif  /* TARGET_PPC64 */
-
 /***Integer load and store multiple***/
 
 /* lmw */
@@ -6614,7 +6602,7 @@ GEN_STS(stw, st32, 0x04, PPC_INTEGER)
 #if defined(TARGET_PPC64)
 GEN_STUX(std, st64_i64, 0x15, 0x05, PPC_64B)
 GEN_STX(std, st64_i64, 0x15, 0x04, PPC_64B)
-GEN_STX_E(stdbr, st64r, 0x14, 0x14, PPC_NONE, PPC2_DBRX, CHK_NONE)
+GEN_STX_E(stdbr, st64r_i64, 0x14, 0x14, PPC_NONE, PPC2_DBRX, CHK_NONE)
 GEN_STX_HVRM(stdcix, st64_i64, 0x15, 0x1f, PPC_CILDST)
 GEN_STX_HVRM(stwcix, st32, 0x15, 0x1c, PPC_CILDST)
 GEN_STX_HVRM(sthcix, st16, 0x15, 0x1d, PPC_CILDST)
-- 
2.7.4




[Qemu-devel] [PATCH v2 01/17] target-ppc: consolidate load operations

2016-08-12 Thread Nikunj A Dadhania
Implement macro to consolidate store operations using newer
tcg_gen_qemu_ld functions.

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c | 58 +-
 1 file changed, 20 insertions(+), 38 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 618334a..30d548a 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -2460,50 +2460,32 @@ static inline void gen_align_no_le(DisasContext *ctx)
 }
 
 /*** Integer load  ***/
-static inline void gen_qemu_ld8u(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-tcg_gen_qemu_ld8u(arg1, arg2, ctx->mem_idx);
-}
-
-static inline void gen_qemu_ld16u(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_UW | ctx->default_tcg_memop_mask;
-tcg_gen_qemu_ld_tl(arg1, arg2, ctx->mem_idx, op);
-}
-
-static inline void gen_qemu_ld16s(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_SW | ctx->default_tcg_memop_mask;
-tcg_gen_qemu_ld_tl(arg1, arg2, ctx->mem_idx, op);
-}
+#define DEF_MEMOP(op) ((op) | ctx->default_tcg_memop_mask)
 
-static inline void gen_qemu_ld32u(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_UL | ctx->default_tcg_memop_mask;
-tcg_gen_qemu_ld_tl(arg1, arg2, ctx->mem_idx, op);
+#define GEN_QEMU_LOAD_TL(ldop, op)  \
+static void glue(gen_qemu_, ldop)(DisasContext *ctx,\
+  TCGv val, \
+  TCGv addr)\
+{   \
+tcg_gen_qemu_ld_tl(val, addr, ctx->mem_idx, op);\
 }
 
-static void gen_qemu_ld32u_i64(DisasContext *ctx, TCGv_i64 val, TCGv addr)
-{
-TCGv tmp = tcg_temp_new();
-gen_qemu_ld32u(ctx, tmp, addr);
-tcg_gen_extu_tl_i64(val, tmp);
-tcg_temp_free(tmp);
-}
+GEN_QEMU_LOAD_TL(ld8u,  DEF_MEMOP(MO_UB))
+GEN_QEMU_LOAD_TL(ld16u, DEF_MEMOP(MO_UW))
+GEN_QEMU_LOAD_TL(ld16s, DEF_MEMOP(MO_SW))
+GEN_QEMU_LOAD_TL(ld32u, DEF_MEMOP(MO_UL))
+GEN_QEMU_LOAD_TL(ld32s, DEF_MEMOP(MO_SL))
 
-static inline void gen_qemu_ld32s(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_SL | ctx->default_tcg_memop_mask;
-tcg_gen_qemu_ld_tl(arg1, arg2, ctx->mem_idx, op);
+#define GEN_QEMU_LOAD_64(ldop, op)  \
+static void glue(gen_qemu_, glue(ldop, _i64))(DisasContext *ctx,\
+ TCGv_i64 val,  \
+ TCGv addr) \
+{   \
+tcg_gen_qemu_ld_i64(val, addr, ctx->mem_idx, op);   \
 }
 
-static void gen_qemu_ld32s_i64(DisasContext *ctx, TCGv_i64 val, TCGv addr)
-{
-TCGv tmp = tcg_temp_new();
-gen_qemu_ld32s(ctx, tmp, addr);
-tcg_gen_ext_tl_i64(val, tmp);
-tcg_temp_free(tmp);
-}
+GEN_QEMU_LOAD_64(ld32u, DEF_MEMOP(MO_UL))
+GEN_QEMU_LOAD_64(ld32s, DEF_MEMOP(MO_SL))
 
 static inline void gen_qemu_ld64(DisasContext *ctx, TCGv_i64 arg1, TCGv arg2)
 {
-- 
2.7.4




[Qemu-devel] [PATCH v2 14/17] target-ppc: improve lxvw4x implementation

2016-08-12 Thread Nikunj A Dadhania
Load 8byte at a time and manipulate.

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/helper.h |  1 +
 target-ppc/mem_helper.c |  5 +
 target-ppc/translate/vsx-impl.inc.c | 34 --
 3 files changed, 26 insertions(+), 14 deletions(-)

diff --git a/target-ppc/helper.h b/target-ppc/helper.h
index 695a2db..ce214f7 100644
--- a/target-ppc/helper.h
+++ b/target-ppc/helper.h
@@ -288,6 +288,7 @@ DEF_HELPER_2(mtvscr, void, env, avr)
 DEF_HELPER_3(lvebx, void, env, avr, tl)
 DEF_HELPER_3(lvehx, void, env, avr, tl)
 DEF_HELPER_3(lvewx, void, env, avr, tl)
+DEF_HELPER_1(bswap32x2, i64, i64)
 DEF_HELPER_3(stvebx, void, env, avr, tl)
 DEF_HELPER_3(stvehx, void, env, avr, tl)
 DEF_HELPER_3(stvewx, void, env, avr, tl)
diff --git a/target-ppc/mem_helper.c b/target-ppc/mem_helper.c
index bf6c44a..070dff6 100644
--- a/target-ppc/mem_helper.c
+++ b/target-ppc/mem_helper.c
@@ -354,6 +354,11 @@ STVE(stvewx, cpu_stl_data_ra, bswap32, u32)
 #undef I
 #undef LVE
 
+uint64_t helper_bswap32x2(uint64_t x)
+{
+return deposit64((x >> 32), 32, 32, (x));
+}
+
 #undef HI_IDX
 #undef LO_IDX
 
diff --git a/target-ppc/translate/vsx-impl.inc.c 
b/target-ppc/translate/vsx-impl.inc.c
index eee6052..e3374df 100644
--- a/target-ppc/translate/vsx-impl.inc.c
+++ b/target-ppc/translate/vsx-impl.inc.c
@@ -75,7 +75,7 @@ static void gen_lxvdsx(DisasContext *ctx)
 static void gen_lxvw4x(DisasContext *ctx)
 {
 TCGv EA;
-TCGv_i64 tmp;
+TCGv_i64 t0, t1;
 TCGv_i64 xth = cpu_vsrh(xT(ctx->opcode));
 TCGv_i64 xtl = cpu_vsrl(xT(ctx->opcode));
 if (unlikely(!ctx->vsx_enabled)) {
@@ -84,22 +84,28 @@ static void gen_lxvw4x(DisasContext *ctx)
 }
 gen_set_access_type(ctx, ACCESS_INT);
 EA = tcg_temp_new();
-tmp = tcg_temp_new_i64();
 
 gen_addr_reg_index(ctx, EA);
-gen_qemu_ld32u_i64(ctx, tmp, EA);
-tcg_gen_addi_tl(EA, EA, 4);
-gen_qemu_ld32u_i64(ctx, xth, EA);
-tcg_gen_deposit_i64(xth, xth, tmp, 32, 32);
-
-tcg_gen_addi_tl(EA, EA, 4);
-gen_qemu_ld32u_i64(ctx, tmp, EA);
-tcg_gen_addi_tl(EA, EA, 4);
-gen_qemu_ld32u_i64(ctx, xtl, EA);
-tcg_gen_deposit_i64(xtl, xtl, tmp, 32, 32);
-
+if (ctx->le_mode) {
+t0 = tcg_temp_new_i64();
+t1 = tcg_temp_new_i64();
+tcg_gen_qemu_ld_i64(t0, EA, ctx->mem_idx, MO_LEQ);
+tcg_gen_shri_i64(t1, t0, 32);
+tcg_gen_deposit_i64(xth, t1, t0, 32, 32);
+tcg_gen_addi_tl(EA, EA, 8);
+tcg_gen_qemu_ld_i64(t0, EA, ctx->mem_idx, MO_LEQ);
+tcg_gen_shri_i64(t1, t0, 32);
+tcg_gen_deposit_i64(xtl, t1, t0, 32, 32);
+tcg_temp_free_i64(t0);
+tcg_temp_free_i64(t1);
+} else {
+tcg_gen_qemu_ld_i64(xth, EA, ctx->mem_idx, MO_LEQ);
+gen_helper_bswap32x2(xth, xth);
+tcg_gen_addi_tl(EA, EA, 8);
+tcg_gen_qemu_ld_i64(xtl, EA, ctx->mem_idx, MO_LEQ);
+gen_helper_bswap32x2(xtl, xtl);
+}
 tcg_temp_free(EA);
-tcg_temp_free_i64(tmp);
 }
 
 #define VSX_STORE_SCALAR(name, operation) \
-- 
2.7.4




[Qemu-devel] [PATCH v2 00/17] POWER9 TCG enablements - part4

2016-08-12 Thread Nikunj A Dadhania
1) Consolidate Load/Store operations using tcg_gen_qemu_ld/st functions
2) This series contains 10 new instructions for POWER9 ISA3.0
   Use newer qemu load/store tcg helpers and optimize stxvw4x and lxvw4x.

Patches:
 01-09:  Cleanup load/store operations in ppc translator 
10:  xxspltib: VSX Vector Splat Immediate Byte
11:  darn: Deliver a random number
12:  lxsibzx - Load VSX Scalar as Integer Byte & Zero Indexed
 lxsihzx - Load VSX Scalar as Integer Halfword & Zero Indexed
13:  stxsibx - Store VSX Scalar as Integer Byte Indexed
 stxsihx - Store VSX Scalar as Integer Halfword Indexed
14:  lxvw4x - improve implementation
15:  lxvb16x: Load VSX Vector Byte*16
 lxvh8x:  Load VSX Vector Halfword*8
16:  stxv4x - improve implementation
17:  stxvb16x: Store VSX Vector Byte*16
 stxvh8x:  Store VSX Vector Halfword*8

Series also available here: https://github.com/nikunjad/qemu/tree/p9-tcg

Changelog:
v1: 
* More load/store cleanups in byte reverse routines
* ld64/st64 converted to newer macro and updated call sites
* Cleanup load with reservation and store conditional
* Return invalid random for darn instruction

v0:
* darn - read /dev/random to get the random number
* xxspltib - make is PPC64 only
* Consolidate load/store operations and use macros to generate qemu_st/ld
* Simplify load/store vsx endian manipulation

Nikunj A Dadhania (16):
  target-ppc: consolidate load operations
  target-ppc: convert ld64 to use new macro
  target-ppc: convert ld[16,32,64]ur to use new macro
  target-ppc: consolidate store operations
  target-ppc: convert st64 to use new macro
  target-ppc: convert st[16,32,64]r to use new macro
  target-ppc: consolidate load with reservation
  target-ppc: move out stqcx impementation
  target-ppc: consolidate store conditional
  target-ppc: add xxspltib instruction
  target-ppc: add lxsi[bw]zx instruction
  target-ppc: add stxsi[bh]x instruction
  target-ppc: improve lxvw4x implementation
  target-ppc: add lxvb16x and lxvh8x
  target-ppc: improve stxvw4x implementation
  target-ppc: add stxvb16x and stxvh8x

Ravi Bangoria (1):
  target-ppc: implement darn instruction

 target-ppc/helper.h |   4 +
 target-ppc/int_helper.c |  16 ++
 target-ppc/mem_helper.c |  11 ++
 target-ppc/translate.c  | 379 +---
 target-ppc/translate/fp-impl.inc.c  |  84 
 target-ppc/translate/fp-ops.inc.c   |   2 +-
 target-ppc/translate/spe-impl.inc.c |   4 +-
 target-ppc/translate/vmx-impl.inc.c |  24 +--
 target-ppc/translate/vsx-impl.inc.c | 208 
 target-ppc/translate/vsx-ops.inc.c  |  13 ++
 10 files changed, 460 insertions(+), 285 deletions(-)

-- 
2.7.4




[Qemu-devel] [PATCH v2 04/17] target-ppc: consolidate store operations

2016-08-12 Thread Nikunj A Dadhania
Implement macro to consolidate store operations using newer
tcg_gen_qemu_st function.

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index a33e0ca..a893c91 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -2496,30 +2496,27 @@ GEN_QEMU_LOAD_64(ld64,  DEF_MEMOP(MO_Q))
 GEN_QEMU_LOAD_64(ld64ur, BSWAP_MEMOP(MO_Q))
 #endif
 
-static inline void gen_qemu_st8(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-tcg_gen_qemu_st8(arg1, arg2, ctx->mem_idx);
+#define GEN_QEMU_STORE_TL(stop, op) \
+static void glue(gen_qemu_, stop)(DisasContext *ctx,\
+  TCGv val, \
+  TCGv addr)\
+{   \
+tcg_gen_qemu_st_tl(val, addr, ctx->mem_idx, op);\
 }
 
-static inline void gen_qemu_st16(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_UW | ctx->default_tcg_memop_mask;
-tcg_gen_qemu_st_tl(arg1, arg2, ctx->mem_idx, op);
-}
+GEN_QEMU_STORE_TL(st8,  DEF_MEMOP(MO_UB))
+GEN_QEMU_STORE_TL(st16, DEF_MEMOP(MO_UW))
+GEN_QEMU_STORE_TL(st32, DEF_MEMOP(MO_UL))
 
-static inline void gen_qemu_st32(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_UL | ctx->default_tcg_memop_mask;
-tcg_gen_qemu_st_tl(arg1, arg2, ctx->mem_idx, op);
+#define GEN_QEMU_STORE_64(stop, op)   \
+static void glue(gen_qemu_, glue(stop, _i64))(DisasContext *ctx,  \
+  TCGv_i64 val,   \
+  TCGv addr)  \
+{ \
+tcg_gen_qemu_st_i64(val, addr, ctx->mem_idx, op); \
 }
 
-static void gen_qemu_st32_i64(DisasContext *ctx, TCGv_i64 val, TCGv addr)
-{
-TCGv tmp = tcg_temp_new();
-tcg_gen_trunc_i64_tl(tmp, val);
-gen_qemu_st32(ctx, tmp, addr);
-tcg_temp_free(tmp);
-}
+GEN_QEMU_STORE_64(st32, DEF_MEMOP(MO_UL))
 
 static inline void gen_qemu_st64(DisasContext *ctx, TCGv_i64 arg1, TCGv arg2)
 {
-- 
2.7.4




[Qemu-devel] [PATCH v2 03/17] target-ppc: convert ld[16, 32, 64]ur to use new macro

2016-08-12 Thread Nikunj A Dadhania
Make byte-swap routines use the common GEN_QEMU_LOAD macro

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c | 27 ++-
 1 file changed, 10 insertions(+), 17 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 42f403a..a33e0ca 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -2461,6 +2461,7 @@ static inline void gen_align_no_le(DisasContext *ctx)
 
 /*** Integer load  ***/
 #define DEF_MEMOP(op) ((op) | ctx->default_tcg_memop_mask)
+#define BSWAP_MEMOP(op) ((op) | (ctx->default_tcg_memop_mask ^ MO_BSWAP))
 
 #define GEN_QEMU_LOAD_TL(ldop, op)  \
 static void glue(gen_qemu_, ldop)(DisasContext *ctx,\
@@ -2476,6 +2477,9 @@ GEN_QEMU_LOAD_TL(ld16s, DEF_MEMOP(MO_SW))
 GEN_QEMU_LOAD_TL(ld32u, DEF_MEMOP(MO_UL))
 GEN_QEMU_LOAD_TL(ld32s, DEF_MEMOP(MO_SL))
 
+GEN_QEMU_LOAD_TL(ld16ur, BSWAP_MEMOP(MO_UW))
+GEN_QEMU_LOAD_TL(ld32ur, BSWAP_MEMOP(MO_UL))
+
 #define GEN_QEMU_LOAD_64(ldop, op)  \
 static void glue(gen_qemu_, glue(ldop, _i64))(DisasContext *ctx,\
  TCGv_i64 val,  \
@@ -2488,6 +2492,10 @@ GEN_QEMU_LOAD_64(ld32u, DEF_MEMOP(MO_UL))
 GEN_QEMU_LOAD_64(ld32s, DEF_MEMOP(MO_SL))
 GEN_QEMU_LOAD_64(ld64,  DEF_MEMOP(MO_Q))
 
+#if defined(TARGET_PPC64)
+GEN_QEMU_LOAD_64(ld64ur, BSWAP_MEMOP(MO_Q))
+#endif
+
 static inline void gen_qemu_st8(DisasContext *ctx, TCGv arg1, TCGv arg2)
 {
 tcg_gen_qemu_st8(arg1, arg2, ctx->mem_idx);
@@ -2834,29 +2842,14 @@ static void gen_std(DisasContext *ctx)
 /***Integer load and store with byte reverse   ***/
 
 /* lhbrx */
-static inline void gen_qemu_ld16ur(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_UW | (ctx->default_tcg_memop_mask ^ MO_BSWAP);
-tcg_gen_qemu_ld_tl(arg1, arg2, ctx->mem_idx, op);
-}
 GEN_LDX(lhbr, ld16ur, 0x16, 0x18, PPC_INTEGER);
 
 /* lwbrx */
-static inline void gen_qemu_ld32ur(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_UL | (ctx->default_tcg_memop_mask ^ MO_BSWAP);
-tcg_gen_qemu_ld_tl(arg1, arg2, ctx->mem_idx, op);
-}
 GEN_LDX(lwbr, ld32ur, 0x16, 0x10, PPC_INTEGER);
 
 #if defined(TARGET_PPC64)
 /* ldbrx */
-static inline void gen_qemu_ld64ur(DisasContext *ctx, TCGv arg1, TCGv arg2)
-{
-TCGMemOp op = MO_Q | (ctx->default_tcg_memop_mask ^ MO_BSWAP);
-tcg_gen_qemu_ld_i64(arg1, arg2, ctx->mem_idx, op);
-}
-GEN_LDX_E(ldbr, ld64ur, 0x14, 0x10, PPC_NONE, PPC2_DBRX, CHK_NONE);
+GEN_LDX_E(ldbr, ld64ur_i64, 0x14, 0x10, PPC_NONE, PPC2_DBRX, CHK_NONE);
 #endif  /* TARGET_PPC64 */
 
 /* sthbrx */
@@ -6593,7 +6586,7 @@ GEN_LDUX(lwa, ld32s, 0x15, 0x0B, PPC_64B)
 GEN_LDX(lwa, ld32s, 0x15, 0x0A, PPC_64B)
 GEN_LDUX(ld, ld64_i64, 0x15, 0x01, PPC_64B)
 GEN_LDX(ld, ld64_i64, 0x15, 0x00, PPC_64B)
-GEN_LDX_E(ldbr, ld64ur, 0x14, 0x10, PPC_NONE, PPC2_DBRX, CHK_NONE)
+GEN_LDX_E(ldbr, ld64ur_i64, 0x14, 0x10, PPC_NONE, PPC2_DBRX, CHK_NONE)
 
 /* HV/P7 and later only */
 GEN_LDX_HVRM(ldcix, ld64_i64, 0x15, 0x1b, PPC_CILDST)
-- 
2.7.4




Re: [Qemu-devel] [PATCH] target-i386: kvm: Report kvm_pv_unhalt as unsupported w/o kernel_irqchip

2016-08-12 Thread Andrew Jones
On Fri, Aug 12, 2016 at 03:14:32PM -0300, Eduardo Habkost wrote:
> The kvm_pv_unhalt feature doesn't work if kernel_irqchip is
> disabled, so we need to report it as unsupported.
> 
> Signed-off-by: Eduardo Habkost 
> ---
>  target-i386/kvm.c | 7 +++
>  1 file changed, 7 insertions(+)

Reviewed-by: Andrew Jones 

> 
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 0b2016a..d1a25c5 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -329,6 +329,13 @@ uint32_t kvm_arch_get_supported_cpuid(KVMState *s, 
> uint32_t function,
>   */
>  cpuid_1_edx = kvm_arch_get_supported_cpuid(s, 1, 0, R_EDX);
>  ret |= cpuid_1_edx & CPUID_EXT2_AMD_ALIASES;
> +} else if (function == KVM_CPUID_FEATURES && reg == R_EAX) {
> +/* kvm_pv_unhalt is reported by GET_SUPPORTED_CPUID, but it can't
> + * be enabled without the in-kernel irqchip
> + */
> +if (!kvm_irqchip_in_kernel()) {
> +ret &= ~(1U << KVM_FEATURE_PV_UNHALT);
> +}
>  }
>  
>  /* fallback for older kernels */
> -- 
> 2.7.4
> 
> 



Re: [Qemu-devel] [PATCH v6 2/4] vfio: VFIO driver for mediated PCI device

2016-08-12 Thread Kirti Wankhede


On 8/12/2016 12:13 AM, Alex Williamson wrote:

> 
> TBH, I don't see how providing a default implementation of
> validate_map_request() is useful.  How many mediated devices are going
> to want to identity map resources from the parent?  Even if they do, it
> seems we can only support a single mediated device per parent device
> since each will map the same parent resource offset. Let's not even try
> to define a default.  If we get a fault and the vendor driver hasn't
> provided a handler, send a SIGBUS.  I expect we should also allow
> vendor drivers to fill the mapping at mmap() time rather than expecting
> this map on fault scheme.  Maybe the mid-level driver should not even be
> interacting with mmap() and should let the vendor driver entirely
> determine the handling.
>

Should we go ahead with pass through mmap() call to vendor driver and
let vendor driver decide what to do in mmap() call, either
remap_pfn_range in mmap() or do fault on access and handle the fault in
their driver. In that case we don't need to track mappings in mdev core.
Let vendor driver do that on their own, right?



> For the most part these mid-level drivers, like mediated pci, should be
> as thin as possible, and to some extent I wonder if we need them at
> all.  We mostly want user interaction with the vfio device file
> descriptor to pass directly to the vendor driver and we should only be
> adding logic to the mid-level driver when it actually provides some
> useful and generic simplification to the vendor driver.  Things like
> this default fault handling scheme don't appear to be generic at all,
> it's actually a very unique use case I think.  For the most part
> I think the mediated interface is just a shim to standardize the
> lifecycle of a mediated device for management purposes,
> integrate "fake/virtual" devices into the vfio infrastructure,
> provide common page tracking, pinning and mapping services, but
> the device interface itself should mostly just pass through the
> vfio device API straight through to the vendor driver.  Thanks,
> 
> Alex
> 



Re: [Qemu-devel] [PATCH for-2.7] target-i386: kvm: Report kvm_pv_unhalt as unsupported w/o kernel_irqchip

2016-08-12 Thread Eduardo Habkost
Sorry, forgot the for-2.7 tag in the Subject. This is a bug fix I
would like to get into QEMU 2.7.

On Fri, Aug 12, 2016 at 03:14:32PM -0300, Eduardo Habkost wrote:
> The kvm_pv_unhalt feature doesn't work if kernel_irqchip is
> disabled, so we need to report it as unsupported.
> 
> Signed-off-by: Eduardo Habkost 
> ---
>  target-i386/kvm.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 0b2016a..d1a25c5 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -329,6 +329,13 @@ uint32_t kvm_arch_get_supported_cpuid(KVMState *s, 
> uint32_t function,
>   */
>  cpuid_1_edx = kvm_arch_get_supported_cpuid(s, 1, 0, R_EDX);
>  ret |= cpuid_1_edx & CPUID_EXT2_AMD_ALIASES;
> +} else if (function == KVM_CPUID_FEATURES && reg == R_EAX) {
> +/* kvm_pv_unhalt is reported by GET_SUPPORTED_CPUID, but it can't
> + * be enabled without the in-kernel irqchip
> + */
> +if (!kvm_irqchip_in_kernel()) {
> +ret &= ~(1U << KVM_FEATURE_PV_UNHALT);
> +}
>  }
>  
>  /* fallback for older kernels */
> -- 
> 2.7.4
> 

-- 
Eduardo



[Qemu-devel] [PATCH] target-i386: kvm: Report kvm_pv_unhalt as unsupported w/o kernel_irqchip

2016-08-12 Thread Eduardo Habkost
The kvm_pv_unhalt feature doesn't work if kernel_irqchip is
disabled, so we need to report it as unsupported.

Signed-off-by: Eduardo Habkost 
---
 target-i386/kvm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 0b2016a..d1a25c5 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -329,6 +329,13 @@ uint32_t kvm_arch_get_supported_cpuid(KVMState *s, 
uint32_t function,
  */
 cpuid_1_edx = kvm_arch_get_supported_cpuid(s, 1, 0, R_EDX);
 ret |= cpuid_1_edx & CPUID_EXT2_AMD_ALIASES;
+} else if (function == KVM_CPUID_FEATURES && reg == R_EAX) {
+/* kvm_pv_unhalt is reported by GET_SUPPORTED_CPUID, but it can't
+ * be enabled without the in-kernel irqchip
+ */
+if (!kvm_irqchip_in_kernel()) {
+ret &= ~(1U << KVM_FEATURE_PV_UNHALT);
+}
 }
 
 /* fallback for older kernels */
-- 
2.7.4




Re: [Qemu-devel] [PATCH V3] hw/misc: Add simple measurement hardware

2016-08-12 Thread Dr. David Alan Gilbert
* Matthew Garrett (mj...@coreos.com) wrote:
> Trusted Boot is based around having a trusted store of measurement data and
> a secure communications channel between that store and an attestation
> target. In actual hardware, that's a TPM. Since the TPM can only be accessed
> via the host system, this in turn requires that the TPM be able to perform
> reasonably complicated cryptographic functions in order to demonstrate its
> trusted state.
> 
> In cloud environments, qemu is inherently trusted and the hypervisor
> infrastructure provides a trusted mechanism for extracting information from
> qemu and providing it to another system. This means we can skip the crypto
> and stick with the basic functionality - ie, providing a trusted store of
> measurement data.
> 
> This driver provides a very small subset of TPM 1.2 functionality in the
> form of a bank of registers that can store SHA1 measurements of boot
> components. Performing a write to one of these registers will append the new
> 20 byte hash to the 20 bytes currently stored within the register, take a
> SHA1 of this 40 byte value and then replace the existing register contents
> with the new value. This ensures that a given value can only be obtained by
> performing the same sequence of writes. It also adds a monitor command to
> allow an external agent to extract this information from the running system
> and provide it over a secure communications channel. Finally, it measures
> each of the loaded ROMs into one of the registers at reset time.
> 
> In combination with work in SeaBIOS and the kernel, this permits a fully
> measured boot in a virtualised environment without the overhead of a full
> TPM implementation.

Do you have SeaBIOS or kernel patches/repos so that people can get a feel
how you're using it?  You could add links here.

(I also still don't quite get how an application interrogating the guest,
over say a net connection to a guest application could pass a nonce to
the hypervisor that's going to sign the measurements).

> This version of the implementation depends on port io, but if there's
> interest I'll add mmio as well.
> 
> Signed-off-by: Matthew Garrett 
> ---
> 
> Updated with Eric's feedback, and made it impossible to enable a TPM and the
> measurement hardware simultaneously. I'm happy to respin this after the
> qmp-commands rework.
> 
>  default-configs/x86_64-softmmu.mak |   1 +
>  hmp-commands-info.hx   |  14 ++
>  hmp.c  |  16 ++
>  hmp.h  |   1 +
>  hw/core/loader.c   |  12 ++
>  hw/i386/acpi-build.c   |  29 +++-
>  hw/misc/Makefile.objs  |   1 +
>  hw/misc/measurements.c | 296 
> +
>  hw/misc/measurements.h |   4 +
>  include/hw/isa/isa.h   |  13 ++
>  include/hw/loader.h|   1 +
>  monitor.c  |   1 +
>  qapi-schema.json   |  30 
>  qmp-commands.hx|  20 +++
>  stubs/Makefile.objs|   1 +
>  stubs/measurements.c   |  19 +++
>  16 files changed, 457 insertions(+), 2 deletions(-)
>  create mode 100644 hw/misc/measurements.c
>  create mode 100644 hw/misc/measurements.h
>  create mode 100644 stubs/measurements.c
> 
> diff --git a/default-configs/x86_64-softmmu.mak 
> b/default-configs/x86_64-softmmu.mak
> index 6e3b312..6f0fcc3 100644
> --- a/default-configs/x86_64-softmmu.mak
> +++ b/default-configs/x86_64-softmmu.mak
> @@ -58,3 +58,4 @@ CONFIG_IOH3420=y
>  CONFIG_I82801B11=y
>  CONFIG_SMBIOS=y
>  CONFIG_HYPERV_TESTDEV=$(CONFIG_KVM)
> +CONFIG_MEASUREMENTS=y
> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> index 74446c6..bf1cf67 100644
> --- a/hmp-commands-info.hx
> +++ b/hmp-commands-info.hx
> @@ -816,6 +816,20 @@ STEXI
>  Show information about hotpluggable CPUs
>  ETEXI
>  
> +{
> +.name   = "measurements",
> +.args_type  = "",
> +.params = "",
> +.help   = "show PCR measurements",
> +.mhandler.cmd = hmp_info_measurements,
> +},
> +
> +STEXI
> +@item info measurements
> +@findex measurements
> +Show PCR measurements
> +ETEXI
> +
>  STEXI
>  @end table
>  ETEXI
> diff --git a/hmp.c b/hmp.c
> index cc2056e..51c0594 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -2038,6 +2038,22 @@ void hmp_info_iothreads(Monitor *mon, const QDict 
> *qdict)
>  qapi_free_IOThreadInfoList(info_list);
>  }
>  
> +void hmp_info_measurements(Monitor *mon, const QDict *qdict)
> +{
> +Error *err = NULL;
> +MeasurementList *info_list = qmp_query_measurements();
> +MeasurementList *info;
> +
> +if (err == NULL) {
> +for (info = info_list; info; info = info->next) {
> +monitor_printf(mon, "%02ld: %s\n", info->value->pcr,
> +   info->value->hash);

I think that's "%02" PRId64 ":%s\n"   (Which I hate but that's portable).

> +  

[Qemu-devel] [PATCH for-2.7? 2/5] block/nbd: Use QemuOpts for runtime options

2016-08-12 Thread Max Reitz
Using QemuOpts will prevent qemu from crashing if the input options have
not been validated (which is the case when they are specified on the
command line or in a json: filename) and some have the wrong type.

Signed-off-by: Max Reitz 
---
 block/nbd.c | 74 -
 1 file changed, 54 insertions(+), 20 deletions(-)

diff --git a/block/nbd.c b/block/nbd.c
index 8d57220..3dec860 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -188,13 +188,13 @@ out:
 g_free(file);
 }
 
-static SocketAddress *nbd_config(BDRVNBDState *s, QDict *options, char 
**export,
+static SocketAddress *nbd_config(BDRVNBDState *s, QemuOpts *opts, char 
**export,
  Error **errp)
 {
 SocketAddress *saddr;
 
-if (qdict_haskey(options, "path") == qdict_haskey(options, "host")) {
-if (qdict_haskey(options, "path")) {
+if (!qemu_opt_get(opts, "path") == !qemu_opt_get(opts, "host")) {
+if (qemu_opt_get(opts, "path")) {
 error_setg(errp, "path and host may not be used at the same 
time.");
 } else {
 error_setg(errp, "one of path and host must be specified.");
@@ -204,32 +204,25 @@ static SocketAddress *nbd_config(BDRVNBDState *s, QDict 
*options, char **export,
 
 saddr = g_new0(SocketAddress, 1);
 
-if (qdict_haskey(options, "path")) {
+if (qemu_opt_get(opts, "path")) {
 UnixSocketAddress *q_unix;
 saddr->type = SOCKET_ADDRESS_KIND_UNIX;
 q_unix = saddr->u.q_unix.data = g_new0(UnixSocketAddress, 1);
-q_unix->path = g_strdup(qdict_get_str(options, "path"));
-qdict_del(options, "path");
+q_unix->path = g_strdup(qemu_opt_get(opts, "path"));
 } else {
 InetSocketAddress *inet;
 saddr->type = SOCKET_ADDRESS_KIND_INET;
 inet = saddr->u.inet.data = g_new0(InetSocketAddress, 1);
-inet->host = g_strdup(qdict_get_str(options, "host"));
-if (!qdict_get_try_str(options, "port")) {
+inet->host = g_strdup(qemu_opt_get(opts, "host"));
+inet->port = g_strdup(qemu_opt_get(opts, "port"));
+if (!inet->port) {
 inet->port = g_strdup_printf("%d", NBD_DEFAULT_PORT);
-} else {
-inet->port = g_strdup(qdict_get_str(options, "port"));
 }
-qdict_del(options, "host");
-qdict_del(options, "port");
 }
 
 s->client.is_unix = saddr->type == SOCKET_ADDRESS_KIND_UNIX;
 
-*export = g_strdup(qdict_get_try_str(options, "export"));
-if (*export) {
-qdict_del(options, "export");
-}
+*export = g_strdup(qemu_opt_get(opts, "export"));
 
 return saddr;
 }
@@ -292,27 +285,67 @@ static QCryptoTLSCreds *nbd_get_tls_creds(const char *id, 
Error **errp)
 }
 
 
+static QemuOptsList runtime_opts = {
+.name = "nbd",
+.head = QTAILQ_HEAD_INITIALIZER(runtime_opts.head),
+.desc = {
+{
+.name = "host",
+.type = QEMU_OPT_STRING,
+.help = "TCP host to connect to",
+},
+{
+.name = "port",
+.type = QEMU_OPT_STRING,
+.help = "TCP port to connect to",
+},
+{
+.name = "path",
+.type = QEMU_OPT_STRING,
+.help = "Unix socket path to connect to",
+},
+{
+.name = "export",
+.type = QEMU_OPT_STRING,
+.help = "Name of the NBD export to open",
+},
+{
+.name = "tls-creds",
+.type = QEMU_OPT_STRING,
+.help = "ID of the TLS credentials to use",
+},
+},
+};
+
 static int nbd_open(BlockDriverState *bs, QDict *options, int flags,
 Error **errp)
 {
 BDRVNBDState *s = bs->opaque;
+QemuOpts *opts = NULL;
+Error *local_err = NULL;
 char *export = NULL;
 QIOChannelSocket *sioc = NULL;
-SocketAddress *saddr;
+SocketAddress *saddr = NULL;
 const char *tlscredsid;
 QCryptoTLSCreds *tlscreds = NULL;
 const char *hostname = NULL;
 int ret = -EINVAL;
 
+opts = qemu_opts_create(_opts, NULL, 0, _abort);
+qemu_opts_absorb_qdict(opts, options, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+goto error;
+}
+
 /* Pop the config into our state object. Exit if invalid. */
-saddr = nbd_config(s, options, , errp);
+saddr = nbd_config(s, opts, , errp);
 if (!saddr) {
 goto error;
 }
 
-tlscredsid = g_strdup(qdict_get_try_str(options, "tls-creds"));
+tlscredsid = g_strdup(qemu_opt_get(opts, "tls-creds"));
 if (tlscredsid) {
-qdict_del(options, "tls-creds");
 tlscreds = nbd_get_tls_creds(tlscredsid, errp);
 if (!tlscreds) {
 goto error;
@@ -346,6 +379,7 @@ static int nbd_open(BlockDriverState *bs, QDict *options, 
int flags,
 }
 qapi_free_SocketAddress(saddr);
 g_free(export);
+

[Qemu-devel] [PATCH for-2.7? 3/5] block/blkdebug: Store config filename

2016-08-12 Thread Max Reitz
Store the configuration file's filename so it can later be used in
bdrv_refresh_filename() without having to directly access the options
QDict which may contain a value of a non-string type.

Signed-off-by: Max Reitz 
---
 block/blkdebug.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/block/blkdebug.c b/block/blkdebug.c
index fb29283..d5db166 100644
--- a/block/blkdebug.c
+++ b/block/blkdebug.c
@@ -39,6 +39,9 @@ typedef struct BDRVBlkdebugState {
 int new_state;
 int align;
 
+/* For blkdebug_refresh_filename() */
+char *config_file;
+
 QLIST_HEAD(, BlkdebugRule) rules[BLKDBG__MAX];
 QSIMPLEQ_HEAD(, BlkdebugRule) active_rules;
 QLIST_HEAD(, BlkdebugSuspendedReq) suspended_reqs;
@@ -351,7 +354,6 @@ static int blkdebug_open(BlockDriverState *bs, QDict 
*options, int flags,
 BDRVBlkdebugState *s = bs->opaque;
 QemuOpts *opts;
 Error *local_err = NULL;
-const char *config;
 uint64_t align;
 int ret;
 
@@ -364,8 +366,8 @@ static int blkdebug_open(BlockDriverState *bs, QDict 
*options, int flags,
 }
 
 /* Read rules from config file or command line options */
-config = qemu_opt_get(opts, "config");
-ret = read_config(s, config, options, errp);
+s->config_file = g_strdup(qemu_opt_get(opts, "config"));
+ret = read_config(s, s->config_file, options, errp);
 if (ret) {
 goto out;
 }
@@ -398,6 +400,9 @@ static int blkdebug_open(BlockDriverState *bs, QDict 
*options, int flags,
 fail_unref:
 bdrv_unref_child(bs, bs->file);
 out:
+if (ret < 0) {
+g_free(s->config_file);
+}
 qemu_opts_del(opts);
 return ret;
 }
@@ -515,6 +520,8 @@ static void blkdebug_close(BlockDriverState *bs)
 remove_rule(rule);
 }
 }
+
+g_free(s->config_file);
 }
 
 static void suspend_request(BlockDriverState *bs, BlkdebugRule *rule)
@@ -679,6 +686,7 @@ static int blkdebug_truncate(BlockDriverState *bs, int64_t 
offset)
 
 static void blkdebug_refresh_filename(BlockDriverState *bs, QDict *options)
 {
+BDRVBlkdebugState *s = bs->opaque;
 QDict *opts;
 const QDictEntry *e;
 bool force_json = false;
@@ -700,8 +708,7 @@ static void blkdebug_refresh_filename(BlockDriverState *bs, 
QDict *options)
 
 if (!force_json && bs->file->bs->exact_filename[0]) {
 snprintf(bs->exact_filename, sizeof(bs->exact_filename),
- "blkdebug:%s:%s",
- qdict_get_try_str(options, "config") ?: "",
+ "blkdebug:%s:%s", s->config_file ?: "",
  bs->file->bs->exact_filename);
 }
 
-- 
2.9.2




[Qemu-devel] [PATCH for-2.7? 0/5] block: Use QemuOpts for runtime options

2016-08-12 Thread Max Reitz
The SSH and NBD block drivers currently directly extract their runtime
options from the options QDict they receive. This is bad practice and
can lead to segmentation faults (which, however, will always be a NULL
pointer dereference, so it should not be exploitable beyond a DoS).

This series fixes that by using QemuOpts instead (like all the other
block drivers do).

With this series applied, there are only two instances of "qdict_get"
left in block/, both of which appear to be safe.


Max Reitz (5):
  block/ssh: Use QemuOpts for runtime options
  block/nbd: Use QemuOpts for runtime options
  block/blkdebug: Store config filename
  block/nbd: Store runtime option values
  iotests: Test case for wrong runtime option types

 block/blkdebug.c   |  17 +++--
 block/nbd.c| 159 ++---
 block/ssh.c|  77 +++---
 tests/qemu-iotests/162 |  96 +++
 tests/qemu-iotests/162.out |  17 +
 tests/qemu-iotests/group   |   1 +
 6 files changed, 284 insertions(+), 83 deletions(-)
 create mode 100755 tests/qemu-iotests/162
 create mode 100644 tests/qemu-iotests/162.out

-- 
2.9.2




[Qemu-devel] [PATCH for-2.7? 5/5] iotests: Test case for wrong runtime option types

2016-08-12 Thread Max Reitz
Signed-off-by: Max Reitz 
---
 tests/qemu-iotests/162 | 96 ++
 tests/qemu-iotests/162.out | 17 
 tests/qemu-iotests/group   |  1 +
 3 files changed, 114 insertions(+)
 create mode 100755 tests/qemu-iotests/162
 create mode 100644 tests/qemu-iotests/162.out

diff --git a/tests/qemu-iotests/162 b/tests/qemu-iotests/162
new file mode 100755
index 000..0b43ea3
--- /dev/null
+++ b/tests/qemu-iotests/162
@@ -0,0 +1,96 @@
+#!/bin/bash
+#
+# Test case for specifying runtime options of the wrong type to some
+# block drivers
+#
+# Copyright (C) 2016 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+# creator
+owner=mre...@redhat.com
+
+seq="$(basename $0)"
+echo "QA output created by $seq"
+
+here="$PWD"
+status=1   # failure is the default!
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt generic
+_supported_os Linux
+
+echo
+echo '=== NBD ==='
+# NBD expects all of its arguments to be strings
+
+# So this should not crash
+$QEMU_IMG info 'json:{"driver": "nbd", "host": 42}'
+
+# And this should not treat @port as if it had not been specified
+# (We cannot use localhost with an invalid port here, but we need to use a
+#  non-existing domain, because otherwise the error message will not contain
+#  the port)
+$QEMU_IMG info 'json:{"driver": "nbd", "host": "does.not.exist.example.com", 
"port": 42}'
+
+# This is a test for NBD's bdrv_refresh_filename() implementation: It expects
+# either host or path to be set, but it must not assume that they are set to
+# strings in the options QDict
+$QEMU_NBD -k "$PWD/42" -f raw null-co:// &
+sleep 0.5
+$QEMU_IMG info 'json:{"driver": "nbd", "path": 42}' | grep '^image'
+rm -f 42
+
+
+echo
+echo '=== SSH ==='
+# SSH expects all of its arguments to be strings, except for @port, which is
+# expected to be an integer
+
+# So "0" should be converted to an integer here (instead of crashing)
+$QEMU_IMG info 'json:{"driver": "ssh", "host": "localhost", "port": "0", 
"path": "/foo"}'
+# The same, basically (all values for --image-opts are seen as strings in qemu)
+$QEMU_IMG info --image-opts \
+driver=ssh,host=localhost,port=0,path=/foo
+
+# This, however, should fail because of the wrong type
+$QEMU_IMG info 'json:{"driver": "ssh", "host": "localhost", "port": 0.42, 
"path": "/foo"}'
+# Not really the same: Here, "0.42" will be passed instead of 0.42, but still,
+# qemu should not try to convert "0.42" to an integer
+$QEMU_IMG info --image-opts \
+driver=ssh,host=localhost,port=0.42,path=/foo
+
+
+echo
+echo '=== blkdebug ==='
+# blkdebug expects all of its arguments to be strings, but its
+# bdrv_refresh_filename() implementation should not assume that they have been
+# passed as strings in the original options QDict.
+# So this should emit blkdebug:42:null-co:// as the filename:
+touch 42
+$QEMU_IMG info 'json:{"driver": "blkdebug", "config": 42,
+  "image.driver": "null-co"}' \
+| grep '^image'
+rm -f 42
+
+
+# success, all done
+echo
+echo '*** done'
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/162.out b/tests/qemu-iotests/162.out
new file mode 100644
index 000..9bba723
--- /dev/null
+++ b/tests/qemu-iotests/162.out
@@ -0,0 +1,17 @@
+QA output created by 162
+
+=== NBD ===
+qemu-img: Could not open 'json:{"driver": "nbd", "host": 42}': Failed to 
connect socket: Invalid argument
+qemu-img: Could not open 'json:{"driver": "nbd", "host": 
"does.not.exist.example.com", "port": 42}': address resolution failed for 
does.not.exist.example.com:42: Name or service not known
+image: nbd+unix://?socket=42
+
+=== SSH ===
+qemu-img: Could not open 'json:{"driver": "ssh", "host": "localhost", "port": 
"0", "path": "/foo"}': Failed to connect socket: Connection refused
+qemu-img: Could not open 'driver=ssh,host=localhost,port=0,path=/foo': Failed 
to connect socket: Connection refused
+qemu-img: Could not open 'json:{"driver": "ssh", "host": "localhost", "port": 
0.42, "path": "/foo"}': Parameter 'port' expects a number
+qemu-img: Could not open 'driver=ssh,host=localhost,port=0.42,path=/foo': 
Parameter 'port' expects a number
+
+=== blkdebug ===
+image: blkdebug:42:null-co://
+
+*** done
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 3a3973e..50ddeed 100644
--- 

[Qemu-devel] [PATCH for-2.7? 1/5] block/ssh: Use QemuOpts for runtime options

2016-08-12 Thread Max Reitz
Using QemuOpts will prevent qemu from crashing if the input options have
not been validated (which is the case when they are specified on the
command line or in a json: filename) and some have the wrong type.

Signed-off-by: Max Reitz 
---
 block/ssh.c | 77 ++---
 1 file changed, 53 insertions(+), 24 deletions(-)

diff --git a/block/ssh.c b/block/ssh.c
index bcbb0e4..4b90f34 100644
--- a/block/ssh.c
+++ b/block/ssh.c
@@ -508,36 +508,73 @@ static int authenticate(BDRVSSHState *s, const char 
*user, Error **errp)
 return ret;
 }
 
+static QemuOptsList runtime_opts = {
+.name = "ssh",
+.head = QTAILQ_HEAD_INITIALIZER(runtime_opts.head),
+.desc = {
+{
+.name = "host",
+.type = QEMU_OPT_STRING,
+.help = "Host to connect to",
+},
+{
+.name = "port",
+.type = QEMU_OPT_NUMBER,
+.help = "Port to connect to",
+},
+{
+.name = "path",
+.type = QEMU_OPT_STRING,
+.help = "Path of the image on the host",
+},
+{
+.name = "user",
+.type = QEMU_OPT_STRING,
+.help = "User as which to connect",
+},
+{
+.name = "host_key_check",
+.type = QEMU_OPT_STRING,
+.help = "Defines how and what to check the host key against",
+},
+},
+};
+
 static int connect_to_ssh(BDRVSSHState *s, QDict *options,
   int ssh_flags, int creat_mode, Error **errp)
 {
 int r, ret;
+QemuOpts *opts = NULL;
+Error *local_err = NULL;
 const char *host, *user, *path, *host_key_check;
 int port;
 
-if (!qdict_haskey(options, "host")) {
+opts = qemu_opts_create(_opts, NULL, 0, _abort);
+qemu_opts_absorb_qdict(opts, options, _err);
+if (local_err) {
 ret = -EINVAL;
-error_setg(errp, "No hostname was specified");
+error_propagate(errp, local_err);
 goto err;
 }
-host = qdict_get_str(options, "host");
 
-if (qdict_haskey(options, "port")) {
-port = qdict_get_int(options, "port");
-} else {
-port = 22;
+host = qemu_opt_get(opts, "host");
+if (!host) {
+ret = -EINVAL;
+error_setg(errp, "No hostname was specified");
+goto err;
 }
 
-if (!qdict_haskey(options, "path")) {
+port = qemu_opt_get_number(opts, "port", 22);
+
+path = qemu_opt_get(opts, "path");
+if (!path) {
 ret = -EINVAL;
 error_setg(errp, "No path was specified");
 goto err;
 }
-path = qdict_get_str(options, "path");
 
-if (qdict_haskey(options, "user")) {
-user = qdict_get_str(options, "user");
-} else {
+user = qemu_opt_get(opts, "user");
+if (!user) {
 user = g_get_user_name();
 if (!user) {
 error_setg_errno(errp, errno, "Can't get user name");
@@ -546,9 +583,8 @@ static int connect_to_ssh(BDRVSSHState *s, QDict *options,
 }
 }
 
-if (qdict_haskey(options, "host_key_check")) {
-host_key_check = qdict_get_str(options, "host_key_check");
-} else {
+host_key_check = qemu_opt_get(opts, "host_key_check");
+if (!host_key_check) {
 host_key_check = "yes";
 }
 
@@ -618,15 +654,6 @@ static int connect_to_ssh(BDRVSSHState *s, QDict *options,
 return -EINVAL;
 }
 
-/* Delete the options we've used; any not deleted will cause the
- * block layer to give an error about unused options.
- */
-qdict_del(options, "host");
-qdict_del(options, "port");
-qdict_del(options, "user");
-qdict_del(options, "path");
-qdict_del(options, "host_key_check");
-
 return 0;
 
  err:
@@ -646,6 +673,8 @@ static int connect_to_ssh(BDRVSSHState *s, QDict *options,
 }
 s->session = NULL;
 
+qemu_opts_del(opts);
+
 return ret;
 }
 
-- 
2.9.2




[Qemu-devel] [PATCH for-2.7? 4/5] block/nbd: Store runtime option values

2016-08-12 Thread Max Reitz
Store the runtime option values in the BDRVNBDState so they can later be
used in nbd_refresh_filename() without having to directly access the
options QDict which may contain values of non-string types.

Signed-off-by: Max Reitz 
---
 block/nbd.c | 105 +++-
 1 file changed, 61 insertions(+), 44 deletions(-)

diff --git a/block/nbd.c b/block/nbd.c
index 3dec860..7403195 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -42,6 +42,9 @@
 
 typedef struct BDRVNBDState {
 NbdClientSession client;
+
+/* For nbd_refresh_filename() */
+char *path, *host, *port, *export, *tlscredsid;
 } BDRVNBDState;
 
 static int nbd_parse_uri(const char *filename, QDict *options)
@@ -188,13 +191,15 @@ out:
 g_free(file);
 }
 
-static SocketAddress *nbd_config(BDRVNBDState *s, QemuOpts *opts, char 
**export,
- Error **errp)
+static SocketAddress *nbd_config(BDRVNBDState *s, QemuOpts *opts, Error **errp)
 {
 SocketAddress *saddr;
 
-if (!qemu_opt_get(opts, "path") == !qemu_opt_get(opts, "host")) {
-if (qemu_opt_get(opts, "path")) {
+s->path = g_strdup(qemu_opt_get(opts, "path"));
+s->host = g_strdup(qemu_opt_get(opts, "host"));
+
+if (!s->path == !s->host) {
+if (s->path) {
 error_setg(errp, "path and host may not be used at the same 
time.");
 } else {
 error_setg(errp, "one of path and host must be specified.");
@@ -204,17 +209,20 @@ static SocketAddress *nbd_config(BDRVNBDState *s, 
QemuOpts *opts, char **export,
 
 saddr = g_new0(SocketAddress, 1);
 
-if (qemu_opt_get(opts, "path")) {
+if (s->path) {
 UnixSocketAddress *q_unix;
 saddr->type = SOCKET_ADDRESS_KIND_UNIX;
 q_unix = saddr->u.q_unix.data = g_new0(UnixSocketAddress, 1);
-q_unix->path = g_strdup(qemu_opt_get(opts, "path"));
+q_unix->path = g_strdup(s->path);
 } else {
 InetSocketAddress *inet;
+
+s->port = g_strdup(qemu_opt_get(opts, "port"));
+
 saddr->type = SOCKET_ADDRESS_KIND_INET;
 inet = saddr->u.inet.data = g_new0(InetSocketAddress, 1);
-inet->host = g_strdup(qemu_opt_get(opts, "host"));
-inet->port = g_strdup(qemu_opt_get(opts, "port"));
+inet->host = g_strdup(s->host);
+inet->port = g_strdup(s->port);
 if (!inet->port) {
 inet->port = g_strdup_printf("%d", NBD_DEFAULT_PORT);
 }
@@ -222,7 +230,7 @@ static SocketAddress *nbd_config(BDRVNBDState *s, QemuOpts 
*opts, char **export,
 
 s->client.is_unix = saddr->type == SOCKET_ADDRESS_KIND_UNIX;
 
-*export = g_strdup(qemu_opt_get(opts, "export"));
+s->export = g_strdup(qemu_opt_get(opts, "export"));
 
 return saddr;
 }
@@ -323,10 +331,8 @@ static int nbd_open(BlockDriverState *bs, QDict *options, 
int flags,
 BDRVNBDState *s = bs->opaque;
 QemuOpts *opts = NULL;
 Error *local_err = NULL;
-char *export = NULL;
 QIOChannelSocket *sioc = NULL;
 SocketAddress *saddr = NULL;
-const char *tlscredsid;
 QCryptoTLSCreds *tlscreds = NULL;
 const char *hostname = NULL;
 int ret = -EINVAL;
@@ -339,14 +345,14 @@ static int nbd_open(BlockDriverState *bs, QDict *options, 
int flags,
 }
 
 /* Pop the config into our state object. Exit if invalid. */
-saddr = nbd_config(s, opts, , errp);
+saddr = nbd_config(s, opts, errp);
 if (!saddr) {
 goto error;
 }
 
-tlscredsid = g_strdup(qemu_opt_get(opts, "tls-creds"));
-if (tlscredsid) {
-tlscreds = nbd_get_tls_creds(tlscredsid, errp);
+s->tlscredsid = g_strdup(qemu_opt_get(opts, "tls-creds"));
+if (s->tlscredsid) {
+tlscreds = nbd_get_tls_creds(s->tlscredsid, errp);
 if (!tlscreds) {
 goto error;
 }
@@ -368,7 +374,7 @@ static int nbd_open(BlockDriverState *bs, QDict *options, 
int flags,
 }
 
 /* NBD handshake */
-ret = nbd_client_init(bs, sioc, export,
+ret = nbd_client_init(bs, sioc, s->export,
   tlscreds, hostname, errp);
  error:
 if (sioc) {
@@ -377,8 +383,14 @@ static int nbd_open(BlockDriverState *bs, QDict *options, 
int flags,
 if (tlscreds) {
 object_unref(OBJECT(tlscreds));
 }
+if (ret < 0) {
+g_free(s->path);
+g_free(s->host);
+g_free(s->port);
+g_free(s->export);
+g_free(s->tlscredsid);
+}
 qapi_free_SocketAddress(saddr);
-g_free(export);
 qemu_opts_del(opts);
 return ret;
 }
@@ -396,7 +408,15 @@ static void nbd_refresh_limits(BlockDriverState *bs, Error 
**errp)
 
 static void nbd_close(BlockDriverState *bs)
 {
+BDRVNBDState *s = bs->opaque;
+
 nbd_client_close(bs);
+
+g_free(s->path);
+g_free(s->host);
+g_free(s->port);
+g_free(s->export);
+g_free(s->tlscredsid);
 }
 
 static int64_t nbd_getlength(BlockDriverState *bs)
@@ -419,48 +439,45 @@ static 

[Qemu-devel] [PATCH] build-sys: fix make check with --disable-vnc

2016-08-12 Thread Marc-André Lureau
Signed-off-by: Marc-André Lureau 
---
 tests/ide-test.c  | 2 ++
 tests/ipmi-bt-test.c  | 5 -
 tests/ipmi-kcs-test.c | 8 ++--
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/tests/ide-test.c b/tests/ide-test.c
index 1e51af2..f6e10ad 100644
--- a/tests/ide-test.c
+++ b/tests/ide-test.c
@@ -582,7 +582,9 @@ static void test_retry_flush(const char *machine)
 prepare_blkdebug_script(debug_path, "flush_to_disk");
 
 ide_test_start(
+#ifdef CONFIG_VNC
 "-vnc none "
+#endif
 "-drive file=blkdebug:%s:%s,if=ide,cache=writeback,format=raw,"
 "rerror=stop,werror=stop",
 debug_path, tmp_path);
diff --git a/tests/ipmi-bt-test.c b/tests/ipmi-bt-test.c
index be9005e..40d456a 100644
--- a/tests/ipmi-bt-test.c
+++ b/tests/ipmi-bt-test.c
@@ -415,7 +415,10 @@ int main(int argc, char **argv)
 /* Run the tests */
 g_test_init(, , NULL);
 
-cmdline = g_strdup_printf("-vnc none"
+cmdline = g_strdup_printf(
+#ifdef CONFIG_VNC
+  "-vnc none"
+#endif
   " -chardev socket,id=ipmi0,host=localhost,port=%d,reconnect=10"
   " -device ipmi-bmc-extern,chardev=ipmi0,id=bmc0"
   " -device isa-ipmi-bt,bmc=bmc0", emu_port);
diff --git a/tests/ipmi-kcs-test.c b/tests/ipmi-kcs-test.c
index 3750389..451feb3 100644
--- a/tests/ipmi-kcs-test.c
+++ b/tests/ipmi-kcs-test.c
@@ -276,8 +276,12 @@ int main(int argc, char **argv)
 /* Run the tests */
 g_test_init(, , NULL);
 
-cmdline = g_strdup_printf("-vnc none -device ipmi-bmc-sim,id=bmc0"
-  " -device isa-ipmi-kcs,bmc=bmc0");
+cmdline = g_strdup_printf(
+#ifdef CONFIG_VNC
+"-vnc none"
+#endif
+" -device ipmi-bmc-sim,id=bmc0"
+" -device isa-ipmi-kcs,bmc=bmc0");
 qtest_start(cmdline);
 qtest_irq_intercept_in(global_qtest, "ioapic");
 qtest_add_func("/ipmi/local/kcs_base", test_kcs_base);
-- 
2.9.0




Re: [Qemu-devel] [PATCH] build-sys: update configure --enable/disable list

2016-08-12 Thread Peter Maydell
On 12 August 2016 at 16:52, Marc-André Lureau
 wrote:
> Add some missing flags description.
>
> Signed-off-by: Marc-André Lureau 
> ---
>  configure | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/configure b/configure
> index 8d84919..352cbdd 100755
> --- a/configure
> +++ b/configure
> @@ -1324,9 +1324,11 @@ disabled with --disable-FEATURE, default is enabled if 
> available:
>guest-agent build the QEMU Guest Agent
>guest-agent-msi build guest agent Windows MSI installation package
>pie Position Independent Executables
> +  tools   build tools (qemu-img, qemu-nbd, ivshmem-server...)

I think this would be slightly clearer as "build the tools".

> +  virglrenderer   virgl 3d rendering

"3D".

thanks
-- PMM



Re: [Qemu-devel] [PATCH] build-sys: update configure --enable/disable list

2016-08-12 Thread Peter Maydell
On 12 August 2016 at 17:48, Marc-André Lureau  wrote:
> Hi
>
> - Original Message -
>> On 12 August 2016 at 16:52, Marc-André Lureau
>>  wrote:
>> > Add some missing flags description.
>> >
>> > Signed-off-by: Marc-André Lureau 
>> > ---
>> >  configure | 6 ++
>> >  1 file changed, 6 insertions(+)
>> >
>> > diff --git a/configure b/configure
>> > index 8d84919..352cbdd 100755
>> > --- a/configure
>> > +++ b/configure
>> > @@ -1324,9 +1324,11 @@ disabled with --disable-FEATURE, default is enabled
>> > if available:
>> >guest-agent build the QEMU Guest Agent
>> >guest-agent-msi build guest agent Windows MSI installation package
>> >pie Position Independent Executables
>> > +  tools   build tools (qemu-img, qemu-nbd, ivshmem-server...)
>>
>> I think this would be slightly clearer as "build the tools".
>
> Ok, along with "build the guest agent" above change then?

You can change that if you like. I just thought that it was
worth having the 'the' in the tools case because "build tools"
is a familiar noun phrase which is misleading here.

thanks
-- PMM



Re: [Qemu-devel] [PULL 3/3] vhost-user: Attempt to fix a race with set_mem_table.

2016-08-12 Thread Prerna Saxena

On 12/08/16 12:08 pm, "Fam Zheng"  wrote:





>On Wed, 08/10 18:30, Michael S. Tsirkin wrote:
>> From: Prerna Saxena 
>> 
>> The set_mem_table command currently does not seek a reply. Hence, there is
>> no easy way for a remote application to notify to QEMU when it finished
>> setting up memory, or if there were errors doing so.
>> 
>> As an example:
>> (1) Qemu sends a SET_MEM_TABLE to the backend (eg, a vhost-user net
>> application). SET_MEM_TABLE does not require a reply according to the spec.
>> (2) Qemu commits the memory to the guest.
>> (3) Guest issues an I/O operation over a new memory region which was 
>> configured on (1).
>> (4) The application has not yet remapped the memory, but it sees the I/O 
>> request.
>> (5) The application cannot satisfy the request because it does not know 
>> about those GPAs.
>> 
>> While a guaranteed fix would require a protocol extension (committed 
>> separately),
>> a best-effort workaround for existing applications is to send a GET_FEATURES
>> message before completing the vhost_user_set_mem_table() call.
>> Since GET_FEATURES requires a reply, an application that processes vhost-user
>> messages synchronously would probably have completed the SET_MEM_TABLE 
>> before replying.
>> 
>> Signed-off-by: Prerna Saxena 
>> Reviewed-by: Michael S. Tsirkin 
>> Signed-off-by: Michael S. Tsirkin 
>
>Sporadic hangs are seen with test-vhost-user after this patch:
>
>https://travis-ci.org/qemu/qemu/builds
>
>Reverting seems to fix it for me.
>
>Is this a known problem?
>
>Fam

Hi Fam,
Thanks for reporting the sporadic hangs. I had seen ‘make check’ pass on my 
Centos 6 environment, so missed this.
I am setting up the docker test env to repro this, but I think I can guess the 
problem :

In tests/vhost-user-test.c: 

static void chr_read(void *opaque, const uint8_t *buf, int size)
{
..[snip]..

case VHOST_USER_SET_MEM_TABLE:
   /* received the mem table */
   memcpy(>memory, , sizeof(msg.payload.memory));
   s->fds_num = qemu_chr_fe_get_msgfds(chr, s->fds, G_N_ELEMENTS(s->fds));


   /* signal the test that it can continue */
   g_cond_signal(>data_cond);
   break;
..[snip]..
}


The test seems to be marked complete as soon as mem_table is copied. 
However, this patch 3/3 changes the behaviour of the SET_MEM_TABLE vhost 
command implementation with qemu. SET_MEM_TABLE now sends out a new message 
GET_FEATURES, and the call is only completed once it receives features from the 
remote application. (or the test framework, as is the case here.)
While the test itself can be modified (Do not signal completion until we’ve 
sent a follow-up response to GET_FEATURES), I am now wondering if this patch 
may break existing vhost applications too ? If so, reverting it possibly better.
What confuses me is why it doesn’t fail all the time, but only about 20% to 30% 
time as Fam reports. 

Thoughts : Michael, Fam, MarcAndre ?

Regards,
Prerna 


Re: [Qemu-devel] [PATCH V2] add migration capability to bypass the shared memory

2016-08-12 Thread Lai Jiangshan
On Fri, Aug 12, 2016 at 2:48 PM, Li, Liang Z  wrote:
>> >> > BTW. Is it possible to bypass the shared block in the
>> >> 'ram_find_and_save_block'?
>> >> > I mean no to check if a page is dirty for a shared block, it may
>> >> > make things
>> >> faster.
>> >>
>> >> Nice spotted.  That would make things faster.  But once there we
>> >> could split the bitmap by ramblock, and the migration_dirty_pages
>> >> also per block, that would make all the searchs faster, and
>> >> adding/removing blocks of ram much easier.  If we enter optimizing
>> >> that function, we could really do much better that the "again" parameter
>> that we have right now.
>> >>
>> >> Later, Juan.
>>
>>
>> This patch focuses on the core thing: adding the ability to bypass migrating
>> the memory.
>> I don't want to add further optimization for it now.
>> I hope this patch merged solo and earlier.
>> optimization patches can be sent after this patch accepted.
>>
>
> Will you send a v3?

After I had read the current comments, it seems I don't need to update
the patch before any new comment arrived. (if I hadn't missed any
important comment..)

Thanks,
Lai

>
> Liang
>



Re: [Qemu-devel] [PATCH] build-sys: update configure --enable/disable list

2016-08-12 Thread Marc-André Lureau
Hi

- Original Message -
> On 12 August 2016 at 16:52, Marc-André Lureau
>  wrote:
> > Add some missing flags description.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  configure | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/configure b/configure
> > index 8d84919..352cbdd 100755
> > --- a/configure
> > +++ b/configure
> > @@ -1324,9 +1324,11 @@ disabled with --disable-FEATURE, default is enabled
> > if available:
> >guest-agent build the QEMU Guest Agent
> >guest-agent-msi build guest agent Windows MSI installation package
> >pie Position Independent Executables
> > +  tools   build tools (qemu-img, qemu-nbd, ivshmem-server...)
> 
> I think this would be slightly clearer as "build the tools".

Ok, along with "build the guest agent" above change then?

> 
> > +  virglrenderer   virgl 3d rendering
> 
> "3D".
> 

ok



Re: [Qemu-devel] [Qemu-block] [PATCH 0/2] coroutine: Assertions and debugging aids

2016-08-12 Thread Stefan Hajnoczi
On Thu, Aug 11, 2016 at 06:22:20PM +0200, Kevin Wolf wrote:
> A while ago we were debugging a hang where coroutines were waiting for a mutex
> to be unlocked, but we couldn't find out who held the lock. This series adds
> some information to Coroutine and CoMutex that both allows to add a few
> assertions to check locking behaviour and can be used to find the culprit when
> analysing a core dump.
> 
> Kevin Wolf (2):
>   coroutine: Let CoMutex remember who holds it
>   coroutine: Assert that no locks are held on termination
> 
>  include/qemu/coroutine.h |  1 +
>  include/qemu/coroutine_int.h |  1 +
>  util/qemu-coroutine-lock.c   | 14 ++
>  util/qemu-coroutine.c|  1 +
>  4 files changed, 17 insertions(+)
> 
> -- 
> 1.8.3.1
> 
> 

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH] trace-events: fix first line comment in trace-events

2016-08-12 Thread Stefan Hajnoczi
On Mon, Aug 08, 2016 at 05:11:21PM +0200, Laurent Vivier wrote:
> Documentation is docs/tracing.txt instead of docs/trace-events.txt.
> 
> find . -name trace-events -exec \
>  sed -i "s?See docs/trace-events.txt for syntax documentation.?See 
> docs/tracing.txt for syntax documentation.?" \
>  {} \;
> 
> Signed-off-by: Laurent Vivier 
> ---
>  audio/trace-events| 2 +-
>  block/trace-events| 2 +-
>  crypto/trace-events   | 2 +-
>  hw/9pfs/trace-events  | 2 +-
>  hw/acpi/trace-events  | 2 +-
>  hw/alpha/trace-events | 2 +-
>  hw/arm/trace-events   | 2 +-
>  hw/audio/trace-events | 2 +-
>  hw/block/trace-events | 2 +-
>  hw/char/trace-events  | 2 +-
>  hw/display/trace-events   | 2 +-
>  hw/dma/trace-events   | 2 +-
>  hw/i386/trace-events  | 2 +-
>  hw/input/trace-events | 2 +-
>  hw/intc/trace-events  | 2 +-
>  hw/isa/trace-events   | 2 +-
>  hw/misc/trace-events  | 2 +-
>  hw/net/trace-events   | 2 +-
>  hw/nvram/trace-events | 2 +-
>  hw/pci/trace-events   | 2 +-
>  hw/ppc/trace-events   | 2 +-
>  hw/s390x/trace-events | 2 +-
>  hw/scsi/trace-events  | 2 +-
>  hw/sd/trace-events| 2 +-
>  hw/sparc/trace-events | 2 +-
>  hw/timer/trace-events | 2 +-
>  hw/usb/trace-events   | 2 +-
>  hw/vfio/trace-events  | 2 +-
>  hw/virtio/trace-events| 2 +-
>  io/trace-events   | 2 +-
>  linux-user/trace-events   | 2 +-
>  migration/trace-events| 2 +-
>  net/trace-events  | 2 +-
>  qom/trace-events  | 2 +-
>  target-i386/trace-events  | 2 +-
>  target-ppc/trace-events   | 2 +-
>  target-s390x/trace-events | 2 +-
>  target-sparc/trace-events | 2 +-
>  ui/trace-events   | 2 +-
>  util/trace-events | 2 +-
>  40 files changed, 40 insertions(+), 40 deletions(-)

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

Stefan


signature.asc
Description: PGP signature


[Qemu-devel] [PATCH] build-sys: update configure --enable/disable list

2016-08-12 Thread Marc-André Lureau
Add some missing flags description.

Signed-off-by: Marc-André Lureau 
---
 configure | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configure b/configure
index 8d84919..352cbdd 100755
--- a/configure
+++ b/configure
@@ -1324,9 +1324,11 @@ disabled with --disable-FEATURE, default is enabled if 
available:
   guest-agent build the QEMU Guest Agent
   guest-agent-msi build guest agent Windows MSI installation package
   pie Position Independent Executables
+  tools   build tools (qemu-img, qemu-nbd, ivshmem-server...)
   modules modules support
   debug-tcg   TCG debugging (default is disabled)
   debug-info  debugging information
+  qom-cast-debug  QOM debugging
   sparse  sparse checker
 
   gnutls  GNUTLS cryptography support
@@ -1359,10 +1361,14 @@ disabled with --disable-FEATURE, default is enabled if 
available:
   cap-ng  libcap-ng support
   attrattr and xattr support
   vhost-net   vhost-net acceleration support
+  vhost-scsi  vhost-scsi acceleration support
   spice   spice
+  opengl  OpenGL support
+  virglrenderer   virgl 3d rendering
   rbd rados block device (rbd)
   libiscsiiscsi support
   libnfs  nfs support
+  xfsctl  xfsctl support
   smartcard   smartcard support (libcacard)
   libusb  libusb (for usb passthrough)
   usb-redir   usb network redirection support
-- 
2.9.0




Re: [Qemu-devel] [PATCH v1 02/10] target-ppc: consolidate load operations

2016-08-12 Thread Nikunj A Dadhania
Richard Henderson  writes:

> On 08/12/2016 05:52 AM, Nikunj A Dadhania wrote:
>> Richard Henderson  writes:
>>
>>> On 08/10/2016 08:00 PM, Nikunj A Dadhania wrote:
 +#define GEN_QEMU_LOAD_64(ldop, op)  \
 +static void glue(gen_qemu_, glue(ldop, _i64))(DisasContext *ctx,\
 + TCGv_i64 val,  \
 + TCGv addr) \
 +{   \
 +tcg_gen_qemu_ld_i64(val, addr, ctx->mem_idx,\
 +op | ctx->default_tcg_memop_mask);  \
 +}
 +
 +GEN_QEMU_LOAD_64(ld32u, MO_UL)
 +GEN_QEMU_LOAD_64(ld32s, MO_SL)

  static inline void gen_qemu_ld64(DisasContext *ctx, TCGv_i64 arg1, TCGv 
 arg2)
  {
>>>
>>> You can of course include this last function in the cleanup as well.
>>
>> Let me do this as separate patch, as it will need patching at lot of
>> places. This will be function name change: gen_qemu_ld64 =>
>> gen_qemu_ld64_i64
>
> Oh, right, of course.

I have done all these changes, will send to the list after testing.

Regards
Nikunj




Re: [Qemu-devel] [PULL 3/3] vhost-user: Attempt to fix a race with set_mem_table.

2016-08-12 Thread Michael S. Tsirkin
On Fri, Aug 12, 2016 at 01:01:16PM +0100, Peter Maydell wrote:
> On 12 August 2016 at 08:20, Marc-André Lureau  wrote:
> > Hi
> >
> > - Original Message -
> >> sent a follow-up response to GET_FEATURES), I am now wondering if this 
> >> patch
> >> may break existing vhost applications too ? If so, reverting it possibly
> >> better.
> >> What confuses me is why it doesn’t fail all the time, but only about 20% to
> >> 30% time as Fam reports.
> >>
> >> Thoughts : Michael, Fam, MarcAndre ?
> >
> > Indeed, I didn't ack that patch in the first place for that kind of 
> > reasons, so I would revert it.
> 
> 
> If somebody would like to send a revert-patch to the list I'll apply
> it to master (please cc me as I suspect the mailing list server is
> down at the moment...) I've been seeing these failures in the
> build tests I run for merges.
> 
> thanks
> -- PMM

Will do right now.

-- 
MST



Re: [Qemu-devel] [PULL 3/3] vhost-user: Attempt to fix a race with set_mem_table.

2016-08-12 Thread Michael S. Tsirkin
On Fri, Aug 12, 2016 at 03:20:56AM -0400, Marc-André Lureau wrote:
> Hi
> 
> - Original Message -
> > sent a follow-up response to GET_FEATURES), I am now wondering if this patch
> > may break existing vhost applications too ? If so, reverting it possibly
> > better.
> > What confuses me is why it doesn’t fail all the time, but only about 20% to
> > 30% time as Fam reports.
> > 
> > Thoughts : Michael, Fam, MarcAndre ?
> 
> Indeed, I didn't ack that patch in the first place for that kind of reasons, 
> so I would revert it.
> 
> thanks

I guess that's the safest thing to do for 2.7.
At least that's not any worse than 2.6.
I still think it's a good idea long term and test should be fixed,
but let's revert for now.

-- 
MST



[Qemu-devel] [Bug 814222] Re: kvm cannot use vhd files over 127GB

2016-08-12 Thread T. Huth
Looks like Serge's fix has been included here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=efc8243d00ab4cf4fa05a9b
... so let's close this bug now.

** Changed in: qemu
   Status: New => Fix Released

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

Title:
  kvm cannot use vhd files over 127GB

Status in QEMU:
  Fix Released
Status in qemu-kvm package in Ubuntu:
  Fix Released

Bug description:
  The primary use case for using vhds with KVM is to perform a
  conversion to a raw image file so that one could move from Hyper-V to
  Linux-KVM.  See more on this http://blog.allanglesit.com/2011/03
  /linux-kvm-migrating-hyper-v-vhd-images-to-kvm/

  # kvm-img convert -f raw -O vpc /root/file.vhd /root/file.img

  The above works great if you have VHDs smaller than 127GB, however if
  it is larger, then no error is generated during the conversion
  process, but it appears to just process up to that 127GB barrier and
  no more.  Also of note.  VHDs can also be run directly using KVM if
  they are smaller than 127GB.  VHDs can be read and function well using
  virtualbox as well as hyper-v, so I suspect the problem lies not with
  the VHD format (since that has a 2TB limitation).  But instead with
  how qemu-kvm is interpreting them.

  BORING VERSION INFO:
  # cat /etc/issue
  Ubuntu 11.04 \n \l
  # uname -rmiv
  2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64
  # apt-cache policy kvm
  kvm:
Installed: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1
Candidate: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1
Version table:
   *** 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 0
  500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages
  500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages
  100 /var/lib/dpkg/status
   1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4 0
  500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages
  # apt-cache policy libvirt-bin
  libvirt-bin:
Installed: 0.8.8-1ubuntu6.2
Candidate: 0.8.8-1ubuntu6.2
Version table:
   *** 0.8.8-1ubuntu6.2 0
  500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages
  500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages
  100 /var/lib/dpkg/status
   0.8.8-1ubuntu6 0
  500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages

  qemu-img version 0.14.0

  # vboxmanage -v
  4.0.12r72916

  
  REPRODUCTION STEPS (requires Windows 7 or Windows 2008 R2 with < 1GB of free 
space)

  ##  WINDOWS  MACHINE  ##

  Use Computer Management > Disk Management
  -Create 2 VHD files, both dynamically expanding 120GB and 140GB respectively.
  -Do not initialize  or format.

  These files will need to be transferred to an Ubuntu KVM machine (pscp
  is what I used but usb would work as well).

  ##  UBUNTU KVM MACHINE  ##

  # ls *.vhd
  120g-dyn.vhd  140g-dyn.vhd
  # kvm-img info 120g-dyn.vhd 
  image: 120g-dyn.vhd
  file format: vpc
  virtual size: 120G (128847052800 bytes)
  disk size: 244K
  # kvm-img info 140g-dyn.vhd 
  image: 140g-dyn.vhd
  file format: vpc
  virtual size: 127G (13683600 bytes)
  disk size: 284K
  # kvm-img info 120g-dyn.vhd | grep "virtual size"
  virtual size: 120G (128847052800 bytes)
  # kvm-img info 140g-dyn.vhd | grep "virtual size"
  virtual size: 127G (13683600 bytes)

  Regardless of how big the second vhd is I always get a virtual size of
  127G

  Now if we use virtualbox to view the vhds we see markedly different
  results.

  # VBoxManage showhdinfo 120g-dyn.vhd
  UUID: e63681e0-ff12-4114-85de-7d13562b36db
  Accessible:   yes
  Logical size: 122880 MBytes
  Current size on disk: 0 MBytes
  Type: normal (base)
  Storage format:   VHD
  Format variant:   dynamic default
  Location: /root/120g-dyn.vhd
  # VBoxManage showhdinfo 140g-dyn.vhd 
  UUID: 94531905-46b4-469f-bb44-7a7d388fb38f
  Accessible:   yes
  Logical size: 143360 MBytes
  Current size on disk: 0 MBytes
  Type: normal (base)
  Storage format:   VHD
  Format variant:   dynamic default
  Location: /root/140g-dyn.vhd

  # kvm-img convert -f vpc -O raw 120g-dyn.vhd 120g-dyn.img
  #
  # kvm-img convert -f vpc -O raw 140g-dyn.vhd 140g-dyn.img
  #

  # kvm-img info 120g-dyn.img 
  image: 120g-dyn.img
  file format: raw
  virtual size: 120G (128847052800 bytes)
  disk size: 0
  # kvm-img info 120g-dyn.img | grep "virtual size"
  virtual size: 120G (128847052800 bytes)
  # kvm-img info 140g-dyn.img 
  image: 140g-dyn.img
  file format: raw
  virtual size: 127G (13683600 bytes)
  disk size: 0
  # kvm-img info 140g-dyn.img | grep "virtual size"
  virtual size: 127G (13683600 bytes)

  Notice after the conversion the raw image will the taken on the
  

[Qemu-devel] [Bug 939995] Re: v1.0-1172-g235fe3b crashes (opts=0x0)

2016-08-12 Thread T. Huth
Peter's fix had been included here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=967c0da73a7b0da186baba6
... so I think we can close this bug ticket now.

** Changed in: qemu
   Status: New => Fix Released

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

Title:
  v1.0-1172-g235fe3b crashes (opts=0x0)

Status in QEMU:
  Fix Released

Bug description:
  C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L 
..\pc-bios
  GNU gdb (GDB) 7.3
  Copyright (C) 2011 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "mingw32".
  For bug reporting instructions, please see:
  ...
  Reading symbols from 
C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe...
  done.
  (gdb) r
  Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L 
..\\pc-bios
  [New Thread 4724.0x1224]

  Program received signal SIGSEGV, Segmentation fault.
  0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel")
  at qemu-option.c:545
  545 QemuOpt *opt = qemu_opt_find(opts, name);
  (gdb) bt
  #0  0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel")
  at qemu-option.c:545
  #1  0x004c7166 in qemu_main (argc=3, argv=0x3e5200, envp=0x0)
  at C:/msys/home/User/qemu/vl.c:3250
  #2  0x004c906a in SDL_main (argc=3, argv=0x3e5200)
  at C:/msys/home/User/qemu/vl.c:102
  #3  0x0061dcf4 in console_main ()
  #4  0x0061ddb4 in WinMain@16 ()
  #5  0x006329fb in main ()
  (gdb)

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



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

2016-08-12 Thread Andrew Jones

Hi Dou,

I'm catching up on mail after vacation so I reviewed the wrong
version of this patch first... Darn. I'll try again with this
version. Please still check my comments in that old version though,
as I'm going faster through this one and may miss things that are
here too (although not all comments are still applicable)

On Tue, Aug 09, 2016 at 06:24:54PM +0800, Dou Liyang wrote:
> This document describes how to use cpu hotplug in QEMU.
> 
> 
> Signed-off-by: Dou Liyang 
> ---
> 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 | 127 
> +++
>  1 file changed, 127 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..6a2f6f8
> --- /dev/null
> +++ b/docs/cpu-hotplug.txt
> @@ -0,0 +1,127 @@
> +QEMU CPU hotplug
> +
> +
> +This document explains how to use the CPU hotplug feature in QEMU,
> +which regards the CPU as a divece.
> +
> +the -device/device_add and device_del based on CPUs are merged since
> +2.7

... the CPU as a device, using -device/device_add and device_del.

QEMU support was merged for 2.7.

(please use spell check)

> +
> +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
> +amount of CPUs which the guest can grow. This is done at startup time

/amount/number/
/grow/have/

> +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"set the number of CPUs to 'n' [default=1].
/set/sets/
> + - "maxcpus" set the maximum number of CPUs, including offline VCPUs
/set/sets/
> +   for hotplug, etc.
> + - "cores"   set the number of CPU cores on one socket.
/set/sets/
> + - "threads  set the number of threads on one CPU core.
/set/sets/
> + - "sockets  set the number of discrete sockets in the system. On
/set/sets/
> +   sPAPR, sockets have no real meaning, And it has no real effect.
> +
> +For example, the following command-line:
> +
> + qemu [...] -smp 3,maxcpus=10,sockets=2,cores=2,threads=2

Same as my v0 comments. sockets*cores*threads must be exactly maxcpus

> +
> +Creates a guest with 3 VCPUs and it supports up to 10 VCPUs. The
> +CPU topology is sockets (2) * cores (2) * threads (2) and can't be
> +greater than maxcpus. When the guest is booted, the guest will see
> +3 VCPUs. More on this below.
> +
> +Query possible available CPU objects
> +
> +
> +The VCPUs should be hotplugged by socket/core/thread-ids parameters

/ids/id/

> +of the possible available CPUs objects.

describing the available...

> +
> +Before adding the VCPUs, we should know those topology parameters,
> +so that we can find out the available place (socket,core,thread)

/out//
/place/location/

> +for a new VCPU.
> +
> +There are two ways to obtain them:
> +
> +1. from the properties advertised by QEMU via the QMP command
> +query-hotpluggable-cpus.

space this over under the from

> +2. from the corresponding HMP command "info hotpluggable-cpus".
> +
> +For example, a monitor command can be used to list the possible CPU
> +objects:
> +
> +  (qemu) info hotpluggable-cpus
> +
> +Select the hotpluggable CPUs including "CPUInstance Properties" for
> +hotpluging. Such as this:
> +
> +  ...
> +  type: "qemu64-x86_64-cpu"
> +  vcpus_count: "1"
> +  CPUInstance Properties:
> +socket-id: "0"
> +core-id: "1"
> +thread-id: "0"
> +  ...
> +
> +Hotplug CPUs
> +
> +
> +A monitor command can be used to hotplug CPUs:
> +
> + - "device_add": creates a VCPU device and inserts it into the
> + specific place as a device
> +
> +For example, the following command adds a VCPU which has the id cpu1
> +in the last position of the guest's CPU sockets which was discussed
> +earlier by using the socket/core/thread-ids:

Instead of hotplugging to the last position of a previous example,
just create a new example. It's less complex and doesn't lose anything.

> +
> +  (qemu) device_add qemu64-x86_64-cpu,id=cpu9,socket-id=2,core-id=0,
> + thread-id=1

Don't add newlines to example commands unless you can actually add them
when inputting the command. It's better to blow the 80 char limit.

> +
> +Where,
> +
> + - "qemu64-x86_64-cpu" is the CPU model.
> + - "id" is the unique identifier in the device sets. It is required.

/sets/set/

> + - "socket-id/core-id/thread-id" represent the designated position
> +   which is obtained form the above possible list of CPUs.
> +
> +It's also possible to 

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

2016-08-12 Thread Stefan Hajnoczi
The statistics virtqueue is not migrated properly because virtio-balloon
does not include s->stats_vq_elem in the migration stream.

After migration the statistics virtqueue hangs because the host never
completes the last element (s->stats_vq_elem is NULL on the destination
QEMU).  Therefore the guest never submits new elements and the virtqueue
is hung.

Instead of changing the migration stream format in an incompatible way,
detect the migration case and rewind the virtqueue so the last element
can be completed.

Signed-off-by: Stefan Hajnoczi 
---
 hw/virtio/virtio-balloon.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 5af429a..a8d66b9 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -99,6 +99,16 @@ static void balloon_stats_poll_cb(void *opaque)
 VirtIOBalloon *s = opaque;
 VirtIODevice *vdev = VIRTIO_DEVICE(s);
 
+/* After live migration we fetch the current element again */
+if (s->stats_vq_elem == NULL && virtqueue_rewind(s->svq, 1)) {
+VirtQueueElement *elem = virtqueue_pop(s->svq, sizeof(*elem));
+
+if (elem) {
+s->stats_vq_offset = iov_size(elem->out_sg, elem->out_num);
+s->stats_vq_elem = elem;
+}
+}
+
 if (s->stats_vq_elem == NULL || !balloon_stats_supported(s)) {
 /* re-schedule */
 balloon_stats_change_timer(s, s->stats_poll_interval);
-- 
2.7.4




Re: [Qemu-devel] [Qemu-block] [PATCH v7 1/4] blockdev: prepare iSCSI block driver for dynamic loading

2016-08-12 Thread Stefan Hajnoczi
On Mon, Aug 08, 2016 at 02:07:17PM -0400, Colin Lord wrote:
> This commit moves the initialization of the QemuOptsList qemu_iscsi_opts
> struct out of block/iscsi.c in order to allow the iscsi module to be
> dynamically loaded.
> 
> Signed-off-by: Colin Lord 
> Reviewed-by: Fam Zheng 
> ---
>  block/iscsi.c | 36 
>  vl.c  | 40 
>  2 files changed, 40 insertions(+), 36 deletions(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


[Qemu-devel] [PATCH v4 2/2] trace: Avoid implicit bool->integer conversions

2016-08-12 Thread Lluís Vilanova
An explicit if/else is clearer than arithmetic assuming #true is 1,
while the compiler should be able to generate just as optimal code.

Signed-off-by: Lluís Vilanova 
---
 stubs/trace-control.c  |   17 +++--
 trace/control-target.c |   31 ++-
 2 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/stubs/trace-control.c b/stubs/trace-control.c
index 3740c38..2dfcd9f 100644
--- a/stubs/trace-control.c
+++ b/stubs/trace-control.c
@@ -19,10 +19,23 @@ void trace_event_set_state_dynamic_init(TraceEvent *ev, 
bool state)
 void trace_event_set_state_dynamic(TraceEvent *ev, bool state)
 {
 TraceEventID id;
+bool state_pre;
 assert(trace_event_get_state_static(ev));
 id = trace_event_get_id(ev);
-trace_events_enabled_count += state - trace_events_dstate[id];
-trace_events_dstate[id] = state;
+/*
+ * We ignore the "vcpu" property here, since there's no target code. Then
+ * dstate can only be 1 or 0.
+ */
+state_pre = trace_events_dstate[id];
+if (state_pre != state) {
+if (state) {
+trace_events_enabled_count++;
+trace_events_dstate[id] = 1;
+} else {
+trace_events_enabled_count--;
+trace_events_dstate[id] = 0;
+}
+}
 }
 
 void trace_event_set_vcpu_state_dynamic(CPUState *vcpu,
diff --git a/trace/control-target.c b/trace/control-target.c
index 4ee3733..72081e2 100644
--- a/trace/control-target.c
+++ b/trace/control-target.c
@@ -16,10 +16,22 @@
 void trace_event_set_state_dynamic_init(TraceEvent *ev, bool state)
 {
 TraceEventID id = trace_event_get_id(ev);
+bool state_pre;
 assert(trace_event_get_state_static(ev));
-/* Ignore "vcpu" property, since no vCPUs have been created yet */
-trace_events_enabled_count += state - trace_events_dstate[id];
-trace_events_dstate[id] = state;
+/*
+ * We ignore the "vcpu" property here, since no vCPUs have been created
+ * yet. Then dstate can only be 1 or 0.
+ */
+state_pre = trace_events_dstate[id];
+if (state_pre != state) {
+if (state) {
+trace_events_enabled_count++;
+trace_events_dstate[id] = 1;
+} else {
+trace_events_enabled_count--;
+trace_events_dstate[id] = 0;
+}
+}
 }
 
 void trace_event_set_state_dynamic(TraceEvent *ev, bool state)
@@ -31,9 +43,18 @@ void trace_event_set_state_dynamic(TraceEvent *ev, bool 
state)
 trace_event_set_vcpu_state_dynamic(vcpu, ev, state);
 }
 } else {
+/* Without the "vcpu" property, dstate can only be 1 or 0 */
 TraceEventID id = trace_event_get_id(ev);
-trace_events_enabled_count += state - trace_events_dstate[id];
-trace_events_dstate[id] = state;
+bool state_pre = trace_events_dstate[id];
+if (state_pre != state) {
+if (state) {
+trace_events_enabled_count++;
+trace_events_dstate[id] = 1;
+} else {
+trace_events_enabled_count--;
+trace_events_dstate[id] = 0;
+}
+}
 }
 }
 




[Qemu-devel] [PATCH for-2.7 2/4] virtio: decrement vq->inuse in virtqueue_discard()

2016-08-12 Thread Stefan Hajnoczi
virtqueue_descard() moves vq->last_avail_idx back so the element can be
popped again.  It's necessary to decrement vq->inuse to avoid "leaking"
the element count.

Signed-off-by: Stefan Hajnoczi 
---
 hw/virtio/virtio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 4df8274..00158b6 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -268,6 +268,7 @@ void virtqueue_discard(VirtQueue *vq, const 
VirtQueueElement *elem,
unsigned int len)
 {
 vq->last_avail_idx--;
+vq->inuse--;
 virtqueue_unmap_sg(vq, elem, len);
 }
 
-- 
2.7.4




[Qemu-devel] [Bug 918791] Re: qemu-kvm dies when using vmvga driver and unity in the guest

2016-08-12 Thread T. Huth
As far as I can see, this should have been fixed in upstream QEMU by this 
commit here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=8cb6bfb54e91b1a31a
... so closing this issue now.

** Changed in: qemu
   Status: New => Fix Released

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

Title:
  qemu-kvm dies when using vmvga driver and unity in the guest

Status in QEMU:
  Fix Released
Status in qemu-kvm package in Ubuntu:
  Fix Released
Status in xserver-xorg-video-vmware package in Ubuntu:
  Invalid
Status in qemu-kvm source package in Oneiric:
  Won't Fix
Status in xserver-xorg-video-vmware source package in Oneiric:
  Invalid
Status in qemu-kvm source package in Precise:
  Fix Released
Status in xserver-xorg-video-vmware source package in Precise:
  Invalid

Bug description:
  =
  SRU Justification:
  1. impact: kvm crashes
  2. Development fix: don't allow attempts to set_bit to negative offsets
  3. Stable fix: same as development fix
  4. Test case (see below)
  5. Regression potential: if the patch is wrong, graphics for vmware vga over 
vnc could get messed up
  =

  12.04's qemu-kvm has been unstable for me and Marc Deslauriers and I
  figured out it has something to do with the interaction of qemu-kvm,
  unity and the vmvga driver. This is a regression over qemu-kvm in
  11.10.

  TEST CASE:
  1. start a VM that uses unity (eg, 11.04, 11.10 or 12.04). My tests use 
unity-2d on an amd64 host and amd64 guests
  2. on 11.04 and 11.10, open empathy via the messaging indicator and click 
'Chat'. On 12.04, open empathy via the messaging indicator and click 'Chat', 
close the empathy wizard, move the empathy window over the unity luancher (so 
it autohides), then do 'ctrl+alt+t' to open a terminal

  When the launcher tries to auto(un)hide, qemu-kvm dies with this:
  [10574.958149] do_general_protection: 132 callbacks suppressed
  [10574.958154] kvm[13192] general protection ip:7fab9680ea0f sp:74440148 
error:0 in qemu-system-x86_64[7fab966c4000+2c9000]

  Relevant libvirt xml:
  
    
    
  

  If I change to using 'cirrus', then qemu-kvm no longer crashes. Eg:
  
    
    
    
  

  The workaround is therefore to use the cirrus driver instead of vmvga,
  however being able to kill qemu-kvm in this manner is not ideal. Also,
  unfortunately unity-2d does not run with with cirrus driver under
  11.04, so the security and SRU teams are unable to properly test
  updates in GUI applications under unity when using the current 12.04
  qemu-kvm.

  I tried to report this via apport, but apport complained about a CRC
  error, so I could not.

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



Re: [Qemu-devel] [PATCH] intel_iommu: add "eim" property

2016-08-12 Thread Peter Xu
On Fri, Aug 12, 2016 at 10:34:44AM +0200, Paolo Bonzini wrote:
> 
> 
> On 11/08/2016 15:29, Peter Xu wrote:
> > +
> > +static void vtd_eim_prop_set(Object *o, bool value, Error **errp)
> > +{
> > +IntelIOMMUState *s = INTEL_IOMMU_DEVICE(o);
> > +s->eim_supported = value;
> > +}
> > +
> > +static void vtd_instance_init(Object *o)
> > +{
> > +IntelIOMMUState *s = INTEL_IOMMU_DEVICE(o);
> > +
> > +/*
> > + * TODO: we can enable this by default after we have full x2apic
> > + * support.
> > + */
> > +s->eim_supported = false;
> > +object_property_add_bool(o, "eim", vtd_eim_prop_get,
> > + vtd_eim_prop_set, NULL);
> > +}
> > +
> >  static const TypeInfo vtd_info = {
> >  .name  = TYPE_INTEL_IOMMU_DEVICE,
> >  .parent= TYPE_X86_IOMMU_DEVICE,
> > +.instance_init = vtd_instance_init,
> 
> This can use DEFINE_PROP_BOOL.

Right. Will post v2. Thanks!

-- peterx



[Qemu-devel] [Bug 807893] Re: qemu privilege escalation

2016-08-12 Thread T. Huth
According to Stefan, this problem has been fixed by this commit:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=cc4662f9642995c78
... so let's close this bug ticket now.

** Changed in: qemu
   Status: Confirmed => Fix Released

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

Title:
  qemu privilege escalation

Status in QEMU:
  Fix Released

Bug description:
  If qemu is started as root, with -runas, the extra groups is not
  dropped correctly

  /proc/`pidof qemu`/status
  ..
  Uid:100 100 100 100
  Gid:100 100 100 100
  FDSize: 32
  Groups: 0 1 2 3 4 6 10 11 26 27 
  ...

  The fix is to add initgroups() or setgroups(1, [gid]) where
  appropriate to os-posix.c.

  The extra gid's allow read or write access to other files (such as
  /dev etc).

  Emulating the qemu code:

  # python
  ...
  >>> import os
  >>> os.setgid(100)
  >>> os.setuid(100)
  >>> os.execve("/bin/sh", [ "/bin/sh" ], os.environ)
  sh-4.1$ xxd /dev/sda | head -n2
  000: eb48 9000        .H..
  010:          
  sh-4.1$ ls -l /dev/sda
  brw-rw 1 root disk 8, 0 Jul  8 11:54 /dev/sda
  sh-4.1$ id
  uid=100(qemu00) gid=100(users) 
groups=100(users),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video)

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



Re: [Qemu-devel] Hang bug in 80-bit float square root implementation

2016-08-12 Thread Peter Maydell
On 10 August 2016 at 04:35, Andrew Dutcher  wrote:
> Hello!
>
> I ran into an issue where qemu (specifically, the unicorn engine)
> would hang forever in the middle of the emulated square root
> instruction under certain circumstances. I eventually tracked the
> issue down to the square root of an "unnormal" long double, one
> without the integer part bit set.
>
> Test case:
>
> cat > hang.s < .intel_syntax noprefix
>
> .global _start
> _start:
>   xor eax,eax
>   inc eax
>   push eax
>   push eax
>   push eax
>   fld tbyte ptr [esp]
>   fsqrt
>   int 0x80
> EOF
> as --32 hang.s -o hang.o
> ld -melf_i386 hang.o -o hang
> qemu-i386 ./hang
>
> qemu will hang! Assuming it jits the fsqrt as the soft float
> implementation and doesn't just use a native fsqrt instruction. I have
> no idea if qemu can do this, but it doesn't hurt to cover that base.

Hi; thanks for this patch and test case. You're right that QEMU
definitely shouldn't hang here, but I don't think this patch
is the correct fix for it. As you say, there's been variation
in how unnormals (80-bit-precision values with non-zero exponent
field and the 'integer' bit zero) should be handled, but the
Intel 64 and IA-32 architectures software developer's manual says
that "The Intel 387 match coprocessor and later IA-32 processors
generate an invalid-operation exception when [pseudo-NaNs,
pseudo-infinities and un-normal numbers] are encountered as operands"
(page 8-20 in the version of the doc I have). I checked on my
x86 box (a Core i7-3770) and it does indeed do this. Since QEMU
doesn't try to emulate the 287 we can stick to emulating just
the "invalid-operation" behaviour and don't need to also try
to emulate what the 287 did.

I think that would look something like:

if (floatx80_invalid_encoding(x)) {
float_raise(float_flag_invalid, status);
return floatx80_default_nan(status);
}

at the start of the relevant floatx80 functions (which is definitely
more than just the sqrt function; would need to check the Intel
docs for exactly which ones). floatx80_invalid_encoding()
would be a new function that identifies the pseudo-NaN,
pseudo-infinity and un-normal formats.

(The other class of odd encoding is pseudo-denormal, but those
are different because they are still supposed to be handled as
inputs, they just aren't generated as outputs.)

> I've never submitted a patch here before, so I hope this is the right
> way to do it!

It's pretty close. We have some documentation on patch formats
and so on here: http://wiki.qemu.org/Contribute/SubmitAPatch

The most important thing that you need to do is remember to
add a "Signed-off-by:" line; we can fix up most other minor
problems, but without the signed-off-by we can't accept the
patch at all.

thanks
-- PMM



Re: [Qemu-devel] [PULL 3/3] vhost-user: Attempt to fix a race with set_mem_table.

2016-08-12 Thread Marc-André Lureau
Hi

- Original Message -
> On Fri, Aug 12, 2016 at 03:20:56AM -0400, Marc-André Lureau wrote:
> > Hi
> > 
> > - Original Message -
> > > sent a follow-up response to GET_FEATURES), I am now wondering if this
> > > patch
> > > may break existing vhost applications too ? If so, reverting it possibly
> > > better.
> > > What confuses me is why it doesn’t fail all the time, but only about 20%
> > > to
> > > 30% time as Fam reports.
> > > 
> > > Thoughts : Michael, Fam, MarcAndre ?
> > 
> > Indeed, I didn't ack that patch in the first place for that kind of
> > reasons, so I would revert it.
> > 
> > thanks
> 
> I guess that's the safest thing to do for 2.7.
> At least that's not any worse than 2.6.
> I still think it's a good idea long term and test should be fixed,
> but let's revert for now.
> 

What about other backends that may have similar expectations from the protocol.

This patch is a hack, there is no reason to have it upstream. The solution is 
provided with the REPLY_ACK patch.




[Qemu-devel] [PATCH RFC] tests: Run qtest cases in parallel

2016-08-12 Thread Fam Zheng
Previously all test cases in a category, such as check-qtest-y, are
executed in a single long gtester command. This patch separates each
test into its own make target to allow better parallism.

Signed-off-by: Fam Zheng 
---

This saves 50% of the time "make check takes" compared to on master
(I use -j8). RFC because I'm not sure if the new gcov usage is correct
with the now much higher level of parallism compared to before.
---
 tests/Makefile.include | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 14be491..9bf0326 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -691,27 +691,29 @@ GCOV_OPTIONS = -n $(if $(V),-f,)
 # gtester tests, possibly with verbose output
 
 .PHONY: $(patsubst %, check-qtest-%, $(QTEST_TARGETS))
-$(patsubst %, check-qtest-%, $(QTEST_TARGETS)): check-qtest-%: $(check-qtest-y)
+
+qtest-run-%: tests/%
$(if $(CONFIG_GCOV),@rm -f *.gcda */*.gcda */*/*.gcda */*/*/*.gcda,)
-   $(call quiet-command,QTEST_QEMU_BINARY=$*-softmmu/qemu-system-$* \
+   $(call quiet-command,\
+   $(if $(QTEST_TARGET), \
+   
QTEST_QEMU_BINARY=$(QTEST_TARGET)-softmmu/qemu-system-$(QTEST_TARGET)) \
QTEST_QEMU_IMG=qemu-img$(EXESUF) \
MALLOC_PERTURB_=$${MALLOC_PERTURB_:-$$((RANDOM % 255 + 1))} \
-   gtester $(GTESTER_OPTIONS) -m=$(SPEED) $(check-qtest-$*-y) 
$(check-qtest-generic-y),"GTESTER $@")
-   $(if $(CONFIG_GCOV),@for f in $(gcov-files-$*-y) 
$(gcov-files-generic-y); do \
- echo Gcov report for $$f:;\
- $(GCOV) $(GCOV_OPTIONS) $$f -o `dirname $$f`; \
-   done,)
+   gtester $< $(GTESTER_OPTIONS) -m=$(SPEED),"GTESTER $<")
+   $(if $(CONFIG_GCOV), @echo Gcov report for $<:;\
+ $(GCOV) $(GCOV_OPTIONS) $< -o `dirname $<`; \
+   )
+
+$(foreach target, $(QTEST_TARGETS), \
+   $(eval check-qtest-$(target): QTEST_TARGET := $(target)) \
+   $(eval check-qtest-$(target): $(patsubst tests/%, qtest-run-%, \
+ $(check-qtest-y) \
+ $(check-qtest-$(target)-y) \
+ $(check-qtest-generic-y))) \
+)
 
 .PHONY: $(patsubst %, check-%, $(check-unit-y))
-$(patsubst %, check-%, $(check-unit-y)): check-%: %
-   $(if $(CONFIG_GCOV),@rm -f *.gcda */*.gcda */*/*.gcda */*/*/*.gcda,)
-   $(call quiet-command, \
-   MALLOC_PERTURB_=$${MALLOC_PERTURB_:-$$((RANDOM % 255 + 1))} \
-   gtester $(GTESTER_OPTIONS) -m=$(SPEED) $*,"GTESTER $*")
-   $(if $(CONFIG_GCOV),@for f in $(gcov-files-$(subst tests/,,$*)-y) 
$(gcov-files-generic-y); do \
- echo Gcov report for $$f:;\
- $(GCOV) $(GCOV_OPTIONS) $$f -o `dirname $$f`; \
-   done,)
+$(patsubst %, check-%, $(check-unit-y)): check-tests/%: qtest-run-%
 
 # gtester tests with XML output
 
-- 
2.7.4




[Qemu-devel] [Bug 1603734] Re: Hang in fsqrt

2016-08-12 Thread Peter Maydell
Thanks for this bug report. The problem here is that QEMU is not
correctly handling the obsolete "unnormal" 80-bit floating point format.
The Intel architecture reference says that this should be handled by
raising the invalid-input exception and returning the default NaN.

See also the discussion in the mailing list thread "Hang bug in 80-bit
float square root implementation", though the patch there is not the
correct fix for the bug.

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

Title:
  Hang in fsqrt

Status in QEMU:
  New

Bug description:
  At least qemu-i368 and qemu-x86_64 hang in floatx80_sqrt in versions
  2.6.0 and git (2.6.50) for some input values, likely due to an
  infinite loop at fpu/softfloat.c:6569.

  Steps to reproduce:
  1) Compile attached code: gcc -o test test.c -lm
  2) `qemu-i368 test` and `qemu-x86_64 test` will hang at 100% cpu

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



Re: [Qemu-devel] [PATCH v3 00/10] arm: add ast2500 support

2016-08-12 Thread Cédric Le Goater
On 08/11/2016 12:47 PM, Peter Maydell wrote:
> On 2 August 2016 at 18:15, Cédric Le Goater  wrote:
>> On the AST2500, I am still having a little issue under uboot which
>> sets the vbar doing :
>>
>> mcr p15, 0, r0, c12, c0, 0  /* Set VBAR */
>>
>> and this is trapped as an undefined instruction by qemu.
>>
>> Looking at hw/arm/helper.c, the VBAR register seems to be defined
>> only for feature ARM_FEATURE_V7 (v7_cp_reginfo). The AST2500 SoC
>> uses a arm1176 which defines ARM_FEATURE_EL3 which gives us a
>> VBAR_EL3.  According to th specs, the arm1176jzf-s has a Vector
>> Base Address Register. So am I missing something in the board
>> definition or is uboot being too optimistic on the cpu features ?
>> This is confusing for me, some direction would be welcomed :)
> 
> This looks like a bug in helper.c -- we originally added the VBAR
> definition as a bit of a hack since it's only supposed to exist
> in CPUs with the security extensions and at the time we didn't
> implement those at all. It should definitely exist in the 1176
> too, so we should move the definition around somewhere so it does.
> (The 1176 is the only non-v7 CPU with security extensions support,
> which is why it got missed I suspect.)

OK. I will give it a try in a standalone patch. Is there a scenario 
I could use to catch possible regression on other cpus ?  

Thanks,

C.

> thanks
> -- PMM
> 




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

2016-08-12 Thread Andrew Jones
On Mon, Aug 08, 2016 at 10:28:02AM +0800, Dou Liyang wrote:
> This document describes how to use cpu hotplug in QEMU.
> 
> Signed-off-by: Dou Liyang 
> ---
>  docs/cpu-hotplug.txt | 110 
> +++
>  1 file changed, 110 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..d62638e
> --- /dev/null
> +++ b/docs/cpu-hotplug.txt
> @@ -0,0 +1,110 @@
> +QEMU CPU hotplug
> +===
> +
> +This document explains how to use the cpu hotplug feature in QEMU,
> +which is present since v2.6.0.
> +
> +Guest support is required for cpu hotplug to work.
> +
> +CPU hotplug
> +---
> +
> +In order to be able to hotplug cpu, QEMU has to be told what is the

a cpu

> +maximum amount of cpus the guest can grow. This is done at startup

/grow/have/

> +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" set the number of CPUs to 'n' [default=1]

/set/sets/

> + - "maxcpus" maximum number of total cpus, including offlineCPUs for

is the maximum...

remove the word 'total'

> + hotplug, etc
> + - "cores" number of CPU cores on one socket
is the number
> + - "threads= number of threads on one CPU core
is the number
> + - "sockets= number of discrete sockets in the system
is the number
> +
> +
> +For example, the following command-line:
> +
> + qemu [...] -smp 3,maxcpus=10,sockets=2,cores=2,threads=2
> +
> +Creates a guest with 3 cpus and it support up to 10 cpus. The cpu

/it support/supports/

> +topology is sockets (2) * cores (2) * threads (2) and can't greater
> +than maxcpus.

The topology should exactly provide maxcpus, i.e. this example is
wrong because the topology only provides a maximum of 8 cpus, but
maxcpus=10. Indeed specifying maxcpus is redundant when a complete
topology is given.


> When the guest is just booted, the guest will see 3
 ^^ it
> +cpus. so there are seven cpus can be hotplugged by using any

Five cpus may be hotplugged using any ...

> +combination of the available sockets,cores and threads topology or

sockets, cores, and threads

I'm not sure what the "using any combination..." means though.

> +using apic-id.

by using

> +
> +cpu hot-plug
> +---
> +
> +A monitor commands are used to hotplug cpu:

/A monitor/Monitor/
/cpu/cpus/

> +
> + - "device_add": creates a cpu device and inserts it into the
> + specific topology as a device
> +
> +For example, the following commands add a cpu which id is cpu1 to

/commands add/command adds/


> +the guest discussed earlier:

a guest:

> +
> +  (qemu) device_add qemu64-x86_64-cpu,id=cpu1,apic-id=3
> +
> + - "qemu64-x86_64-cpu" is the cpu modle.

/modle/model/

> + - "id" is the unique identifier in the device sets.

/sets/set/

> + - "apic-id" is the hotpluged cpu's physical identification.
> +
> +Another command uses the cpu topology to add the additional cpu in

/the cpu topology/cpu topology/

> +the designated position.
> +
> +For example, the following commands add a cpu in the last position
> +of the guest cpu topology discussed earlier.

command adds a cpu to position socket=2, core=1, thread=1:

> +
> +  (qemu) device_add qemu64-x86_64-cpu,id=cpu1,socket-id=2,core-id=1,
> + thread-id=1
> +
> +It's also possible to start a guest with cpu cold-plugged into the

with a cpu

> +hotpluggable cpu topology.
> +
> +In the following command-line example, a guest which has 3 cpus is
> +created where one of the cpus comes from the "apic-id", and another
> +one comes from "socket-id...". After that, the guest has additional
> +seven cpus to be hot-plug when needed:
> +
> + qemu  [...] -smp 1,maxcpus=10,sockets=2,cores=2,threads=2

Broken example again; 2*2*2 != 10

> + -device qemu64-x86_64-cpu,id=cpu1,apic-id=1
> + -device qemu64-x86_64-cpu,socket-id=2,core-id=1,thread-id=0
> +
> +cpu hot-unplug
> +
> +
> +In order to be able to hot unplug cpu device, QEMU has two ways
> +to remove cpu device.

a cpu device
/ways to remove cpu device/methods of removal;/

> +  1. Using the ids which were assigned when you hot plugged cpus.

s/you hot plugged/hotplugging/

> +  2. Using qom_path where the cpu is located in the guest.

Using the qom_path of the cpu.

> +
> +A monitor commands are used to hot unplug cpus:

/Monitor commands/

> +
> + - "device_del": deletes a cpu device
> +
> +For example, assuming that the cpu device with id "cpu1" exists,
> +the following commands tries to remove it.

/commands/command/
/./:/

> +
> +  (qemu) device_del cpu1
> +
> +If you don't set the ids when you hot plugged cpus.
> +
> +First, you may need to obtain the cpu's qom_path. The following

If the IDs are not set when hotplugging, then the 

[Qemu-devel] [PATCH v4 1/2] trace: Remove 'trace_events_dstate_init'

2016-08-12 Thread Lluís Vilanova
Removes the event state array used for early initialization. Since only
events with the "vcpu" property need a late initialization fixup,
threats their initialization specially.

Assumes that the user won't touch the state of "vcpu" events between
early and late initialization (e.g., through QMP).

Signed-off-by: Lluís Vilanova 
---
 stubs/trace-control.c  |5 +
 trace/control-target.c |9 +
 trace/control.c|   23 ++-
 trace/control.h|3 +++
 trace/event-internal.h |1 +
 5 files changed, 28 insertions(+), 13 deletions(-)

diff --git a/stubs/trace-control.c b/stubs/trace-control.c
index fe59836..3740c38 100644
--- a/stubs/trace-control.c
+++ b/stubs/trace-control.c
@@ -11,6 +11,11 @@
 #include "trace/control.h"
 
 
+void trace_event_set_state_dynamic_init(TraceEvent *ev, bool state)
+{
+trace_event_set_state_dynamic(ev, state);
+}
+
 void trace_event_set_state_dynamic(TraceEvent *ev, bool state)
 {
 TraceEventID id;
diff --git a/trace/control-target.c b/trace/control-target.c
index 74c029a..4ee3733 100644
--- a/trace/control-target.c
+++ b/trace/control-target.c
@@ -13,6 +13,15 @@
 #include "translate-all.h"
 
 
+void trace_event_set_state_dynamic_init(TraceEvent *ev, bool state)
+{
+TraceEventID id = trace_event_get_id(ev);
+assert(trace_event_get_state_static(ev));
+/* Ignore "vcpu" property, since no vCPUs have been created yet */
+trace_events_enabled_count += state - trace_events_dstate[id];
+trace_events_dstate[id] = state;
+}
+
 void trace_event_set_state_dynamic(TraceEvent *ev, bool state)
 {
 CPUState *vcpu;
diff --git a/trace/control.c b/trace/control.c
index d173c09..f6e06cc 100644
--- a/trace/control.c
+++ b/trace/control.c
@@ -31,8 +31,6 @@ int trace_events_enabled_count;
  * - true : Integral counting the number of vCPUs that have this event enabled.
  */
 uint16_t trace_events_dstate[TRACE_EVENT_COUNT];
-/* Marks events for late vCPU state init */
-static bool trace_events_dstate_init[TRACE_EVENT_COUNT];
 
 QemuOptsList qemu_trace_opts = {
 .name = "trace",
@@ -142,10 +140,7 @@ static void do_trace_enable_events(const char *line_buf)
 TraceEvent *ev = NULL;
 while ((ev = trace_event_pattern(line_ptr, ev)) != NULL) {
 if (trace_event_get_state_static(ev)) {
-/* start tracing */
-trace_event_set_state_dynamic(ev, enable);
-/* mark for late vCPU init */
-trace_events_dstate_init[ev->id] = true;
+trace_event_set_state_dynamic_init(ev, enable);
 }
 }
 } else {
@@ -157,10 +152,7 @@ static void do_trace_enable_events(const char *line_buf)
 error_report("WARNING: trace event '%s' is not traceable",
  line_ptr);
 } else {
-/* start tracing */
-trace_event_set_state_dynamic(ev, enable);
-/* mark for late vCPU init */
-trace_events_dstate_init[ev->id] = true;
+trace_event_set_state_dynamic_init(ev, enable);
 }
 }
 }
@@ -275,9 +267,14 @@ void trace_init_vcpu_events(void)
 {
 TraceEvent *ev = NULL;
 while ((ev = trace_event_pattern("*", ev)) != NULL) {
-if (trace_event_is_vcpu(ev) &&
-trace_event_get_state_static(ev) &&
-trace_events_dstate_init[ev->id]) {
+if (trace_event_is_vcpu(ev) && trace_event_get_state_dynamic(ev)) {
+TraceEventID id = trace_event_get_id(ev);
+/* check preconditions */
+assert(trace_events_dstate[id] == 1);
+/* disable early-init state ... */
+trace_events_dstate[id] = 0;
+trace_events_enabled_count--;
+/* ... and properly re-enable */
 trace_event_set_state_dynamic(ev, true);
 }
 }
diff --git a/trace/control.h b/trace/control.h
index 0413b28..27a16fc 100644
--- a/trace/control.h
+++ b/trace/control.h
@@ -274,6 +274,9 @@ char *trace_opt_parse(const char *optarg);
  *
  * Re-synchronize initial event state with vCPUs (which can be created after
  * trace_init_events()).
+ *
+ * Precondition: event states won't be changed between trace_enable_events() 
and
+ * trace_init_vcpu_events() (e.g., through QMP).
  */
 void trace_init_vcpu_events(void);
 
diff --git a/trace/event-internal.h b/trace/event-internal.h
index 5d8fa97..074faf6 100644
--- a/trace/event-internal.h
+++ b/trace/event-internal.h
@@ -29,5 +29,6 @@ typedef struct TraceEvent {
 const bool sstate;
 } TraceEvent;
 
+void trace_event_set_state_dynamic_init(TraceEvent *ev, bool state);
 
 #endif /* TRACE__EVENT_INTERNAL_H */




[Qemu-devel] [Bug 891625] Re: [qemu-kvm] add vhost-net to kvm group udev rules 65-kvm.rules

2016-08-12 Thread T. Huth
Since there is no udev file in upstream QEMU, I guess this bug was meant
for the qemu Ubuntu package instead?

** Project changed: qemu => qemu (Ubuntu)

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

Title:
  [qemu-kvm] add vhost-net to kvm group udev rules 65-kvm.rules

Status in qemu package in Ubuntu:
  New

Bug description:
  Please consider authorizing the kvm group to access vhost-net device, similar 
to the kvm device.
  Thanks!

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



Re: [Qemu-devel] [PATCH v2 0/8] nvdimm: hotplug support

2016-08-12 Thread Igor Mammedov
On Fri, 12 Aug 2016 09:35:12 +0100
Stefan Hajnoczi  wrote:

> On Fri, Aug 12, 2016 at 02:54:02PM +0800, Xiao Guangrong wrote:
> > This patchset is against commit c597dc90fbcd6 (virtio-net: allow increasing
> > rx queue siz) on pci branch of Michael's git tree and can be found at:
> >   https://github.com/xiaogr/qemu.git nvdimm-hotplug-v2
> > 
> > Changelog in v2:
> >Fixed signed integer overflow pointed out by Stefan Hajnoczi
> > 
> > This patchset enables nvdimm hotplug support, it is used as pc-dimm hotplug,
> > for example, a new nvdimm device can be plugged as follows:
> > object_add memory-backend-file,id=mem3,size=10G,mem-path=/home/eric/nvdimm3
> > device_add nvdimm,id=nvdimm3,memdev=mem3
> > 
> > and unplug it as follows:
> > device_del nvdimm3
> > object_del mem3
> > 
> > Xiao Guangrong (8):
> >   acpi nvdimm: fix wrong buffer size returned by DSM method
> >   nvdimm acpi: prebuild nvdimm devices for available slots
> >   nvdimm acpi: introduce _FIT
> >   nvdimm acpi: implement Read FIT function
> >   pc-dimm: introduce prepare_unplug() callback
> >   pc: memhp: do not export nvdimm's memory via _CRS
> >   pc: acpi: memhp: nvdimm hotplug support
> >   nvdimm docs: add nvdimm Read FIT function
> > 
> >  docs/specs/acpi_mem_hotplug.txt  |   4 +-
> >  docs/specs/acpi_nvdimm.txt   |  38 +++-
> >  hw/acpi/ich9.c   |   3 +
> >  hw/acpi/memory_hotplug.c |  21 +++--
> >  hw/acpi/nvdimm.c | 195 
> > +++
> >  hw/acpi/piix4.c  |   3 +
> >  hw/i386/acpi-build.c |  28 +-
> >  hw/mem/nvdimm.c  |  12 ++-
> >  hw/mem/pc-dimm.c |   5 +
> >  include/hw/acpi/memory_hotplug.h |   1 +
> >  include/hw/acpi/pc-hotplug.h |   1 +
> >  include/hw/mem/nvdimm.h  |   6 +-
> >  include/hw/mem/pc-dimm.h |   1 +
> >  13 files changed, 278 insertions(+), 40 deletions(-)
> > 
> > -- 
> > 1.8.3.1
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html  
> 
> Reviewed-by: Stefan Hajnoczi 
I'd like to review it but I need to read NVDIMM/ACPI specs first
to make sensible comments.

However it will take some time and I'm on vacation starting next week
and I'll be back in a month. So please don't apply this series until
I'm back and have a chance to review it.






Re: [Qemu-devel] [PATCH v7 0/4] Dynamic module loading for block drivers

2016-08-12 Thread Max Reitz
On 08.08.2016 20:07, Colin Lord wrote:
> One more minor revision from v6, no big changes.
> 
> v7:
> - Add ifdef around qemu_iscsi_opts in vl.c (first patch)
> 
> v6:
> - Fix bug so that users can specify a modularized driver on the cli
>   without qemu exiting
> - Remove extra lines from Makefile
> - Add patch to modularize NFS
> 
> v5:
> - No format drivers are modularized, therefore the probe functions are
>   all being left completely untouched.
> - Remove dmg from block-obj-m since it is not a target of the
>   modularization effort.
> - Modify module_block.py to only include the library name and protocol
>   name fields in the generated struct. The other fields are no longer
>   necessary for the drivers that are being modularized.
> 
> v4:
> - Fix indentation of the generated header file module_block.h
> - Drivers and probe functions are now all located in the block/
>   directory, rather than being split between block/ and block/probe/. In
>   addition the header files for each probe/driver pair are in the block/
>   directory, not the include/block/driver/ directory (which no longer
>   exists).
> - Since the probe files are in block/ now, they follow the naming
>   pattern of format-probe.c
> - Renamed crypto probe file to be crypto-probe.c, luks is no longer in
>   the filename
> - Fixed formatting of parallels_probe() function header
> - Enforced consistent naming convention for the probe functions. They
>   now follow the pattern bdrv_format_probe().
> 
> Colin Lord (2):
>   blockdev: prepare iSCSI block driver for dynamic loading
>   blockdev: Modularize nfs block driver
> 
> Marc Mari (2):
>   blockdev: Add dynamic generation of module_block.h
>   blockdev: Add dynamic module loading for block drivers
> 
>  Makefile|  10 ++--
>  block.c |  62 ---
>  block/Makefile.objs |   4 +-
>  block/iscsi.c   |  36 --
>  configure   |   4 +-
>  include/qemu/module.h   |   3 ++
>  scripts/modules/module_block.py | 108 
> 
>  util/module.c   |  38 --
>  vl.c|  40 +++
>  9 files changed, 228 insertions(+), 77 deletions(-)
>  create mode 100644 scripts/modules/module_block.py

I'd be happy to apply the series as-is, but I'll still give you some
time to decide whether you want to extend patch 3's commit message by
what Fam has proposed.

Max



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH v4 0/2] trace: Simplify late initialization

2016-08-12 Thread Lluís Vilanova
Removes the need for 'trace_events_dstate_init' and does a little cleanup in how
state values are modified (to avoid implicit conversions from bool).

Changes in v2
=

* Fix late-init state value [Daniel P. Berrange].

Changes in v3
=

* Avoid implicit conversions from bool to integers (second patch) [Daniel
  P. Berrange].

Changes in v4
=

* Correctly implement idempotent state changes.
* Clarify when state changes are idempotent [Daniel P. Berrange].

Signed-off-by: Lluís Vilanova 
---

Lluís Vilanova (2):
  trace: Remove 'trace_events_dstate_init'
  trace: Avoid implicit bool->integer conversions


 stubs/trace-control.c  |   22 --
 trace/control-target.c |   34 --
 trace/control.c|   23 ++-
 trace/control.h|3 +++
 trace/event-internal.h |1 +
 5 files changed, 66 insertions(+), 17 deletions(-)


To: qemu-devel@nongnu.org
Cc: Stefan Hajnoczi 
Cc: 'Daniel P. Berrange' 
Cc: Paolo Bonzini 



[Qemu-devel] [PATCH for-2.7 3/4] virtio: add virtqueue_rewind()

2016-08-12 Thread Stefan Hajnoczi
virtqueue_discard() requires a VirtQueueElement but virtio-balloon does
not migrate its in-use element.  Introduce a new function that is
similar to virtqueue_discard() but doesn't require a VirtQueueElement.

This will allow virtio-balloon to access element again after migration
with the usual proviso that the guest may have modified the vring since
last time.

Signed-off-by: Stefan Hajnoczi 
---
 hw/virtio/virtio.c | 22 ++
 include/hw/virtio/virtio.h |  1 +
 2 files changed, 23 insertions(+)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 00158b6..22727ba 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -272,6 +272,28 @@ void virtqueue_discard(VirtQueue *vq, const 
VirtQueueElement *elem,
 virtqueue_unmap_sg(vq, elem, len);
 }
 
+/* virtqueue_rewind:
+ * @vq: The #VirtQueue
+ * @num: Number of elements to push back
+ *
+ * Pretend that elements weren't popped from the virtqueue.  The next
+ * virtqueue_pop() will refetch the oldest element.
+ *
+ * Use virtqueue_discard() instead if you have a VirtQueueElement.
+ *
+ * Returns: true on success, false if @num is greater than the number of in use
+ * elements.
+ */
+bool virtqueue_rewind(VirtQueue *vq, unsigned int num)
+{
+if (num > vq->inuse) {
+return false;
+}
+vq->last_avail_idx -= num;
+vq->inuse -= num;
+return true;
+}
+
 void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
 unsigned int len, unsigned int idx)
 {
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index d2490c1..f05559d 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -154,6 +154,7 @@ void virtqueue_push(VirtQueue *vq, const VirtQueueElement 
*elem,
 void virtqueue_flush(VirtQueue *vq, unsigned int count);
 void virtqueue_discard(VirtQueue *vq, const VirtQueueElement *elem,
unsigned int len);
+bool virtqueue_rewind(VirtQueue *vq, unsigned int num);
 void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
 unsigned int len, unsigned int idx);
 
-- 
2.7.4




Re: [Qemu-devel] [PULL 3/3] vhost-user: Attempt to fix a race with set_mem_table.

2016-08-12 Thread Marc-André Lureau
Hi

- Original Message -
> sent a follow-up response to GET_FEATURES), I am now wondering if this patch
> may break existing vhost applications too ? If so, reverting it possibly
> better.
> What confuses me is why it doesn’t fail all the time, but only about 20% to
> 30% time as Fam reports.
> 
> Thoughts : Michael, Fam, MarcAndre ?

Indeed, I didn't ack that patch in the first place for that kind of reasons, so 
I would revert it.

thanks



[Qemu-devel] [PULL for-2.7 1/1] trace-events: fix first line comment in trace-events

2016-08-12 Thread Stefan Hajnoczi
From: Laurent Vivier 

Documentation is docs/tracing.txt instead of docs/trace-events.txt.

find . -name trace-events -exec \
 sed -i "s?See docs/trace-events.txt for syntax documentation.?See 
docs/tracing.txt for syntax documentation.?" \
 {} \;

Signed-off-by: Laurent Vivier 
Message-id: 1470669081-17860-1-git-send-email-lviv...@redhat.com
Signed-off-by: Stefan Hajnoczi 
---
 audio/trace-events| 2 +-
 block/trace-events| 2 +-
 crypto/trace-events   | 2 +-
 hw/9pfs/trace-events  | 2 +-
 hw/acpi/trace-events  | 2 +-
 hw/alpha/trace-events | 2 +-
 hw/arm/trace-events   | 2 +-
 hw/audio/trace-events | 2 +-
 hw/block/trace-events | 2 +-
 hw/char/trace-events  | 2 +-
 hw/display/trace-events   | 2 +-
 hw/dma/trace-events   | 2 +-
 hw/i386/trace-events  | 2 +-
 hw/input/trace-events | 2 +-
 hw/intc/trace-events  | 2 +-
 hw/isa/trace-events   | 2 +-
 hw/misc/trace-events  | 2 +-
 hw/net/trace-events   | 2 +-
 hw/nvram/trace-events | 2 +-
 hw/pci/trace-events   | 2 +-
 hw/ppc/trace-events   | 2 +-
 hw/s390x/trace-events | 2 +-
 hw/scsi/trace-events  | 2 +-
 hw/sd/trace-events| 2 +-
 hw/sparc/trace-events | 2 +-
 hw/timer/trace-events | 2 +-
 hw/usb/trace-events   | 2 +-
 hw/vfio/trace-events  | 2 +-
 hw/virtio/trace-events| 2 +-
 io/trace-events   | 2 +-
 linux-user/trace-events   | 2 +-
 migration/trace-events| 2 +-
 net/trace-events  | 2 +-
 qom/trace-events  | 2 +-
 target-i386/trace-events  | 2 +-
 target-ppc/trace-events   | 2 +-
 target-s390x/trace-events | 2 +-
 target-sparc/trace-events | 2 +-
 ui/trace-events   | 2 +-
 util/trace-events | 2 +-
 40 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/audio/trace-events b/audio/trace-events
index 5638ea1..5173590 100644
--- a/audio/trace-events
+++ b/audio/trace-events
@@ -1,4 +1,4 @@
-# See docs/trace-events.txt for syntax documentation.
+# See docs/tracing.txt for syntax documentation.
 
 # audio/alsaaudio.c
 alsa_revents(int revents) "revents = %d"
diff --git a/block/trace-events b/block/trace-events
index 978ef4f..05fa13c 100644
--- a/block/trace-events
+++ b/block/trace-events
@@ -1,4 +1,4 @@
-# See docs/trace-events.txt for syntax documentation.
+# See docs/tracing.txt for syntax documentation.
 
 # block.c
 bdrv_open_common(void *bs, const char *filename, int flags, const char 
*format_name) "bs %p filename \"%s\" flags %#x format_name \"%s\""
diff --git a/crypto/trace-events b/crypto/trace-events
index 71f1d99..8181843 100644
--- a/crypto/trace-events
+++ b/crypto/trace-events
@@ -1,4 +1,4 @@
-# See docs/trace-events.txt for syntax documentation.
+# See docs/tracing.txt for syntax documentation.
 
 # crypto/tlscreds.c
 qcrypto_tls_creds_load_dh(void *creds, const char *filename) "TLS creds load 
DH creds=%p filename=%s"
diff --git a/hw/9pfs/trace-events b/hw/9pfs/trace-events
index 63efa27..48d3d8a 100644
--- a/hw/9pfs/trace-events
+++ b/hw/9pfs/trace-events
@@ -1,4 +1,4 @@
-# See docs/trace-events.txt for syntax documentation.
+# See docs/tracing.txt for syntax documentation.
 
 # hw/9pfs/virtio-9p.c
 v9fs_rerror(uint16_t tag, uint8_t id, int err) "tag %d id %d err %d"
diff --git a/hw/acpi/trace-events b/hw/acpi/trace-events
index 5aa3ba6..c379607 100644
--- a/hw/acpi/trace-events
+++ b/hw/acpi/trace-events
@@ -1,4 +1,4 @@
-# See docs/trace-events.txt for syntax documentation.
+# See docs/tracing.txt for syntax documentation.
 
 # hw/acpi/memory_hotplug.c
 mhp_acpi_invalid_slot_selected(uint32_t slot) "0x%"PRIx32
diff --git a/hw/alpha/trace-events b/hw/alpha/trace-events
index 7d52b5d..e44ff01 100644
--- a/hw/alpha/trace-events
+++ b/hw/alpha/trace-events
@@ -1,4 +1,4 @@
-# See docs/trace-events.txt for syntax documentation.
+# See docs/tracing.txt for syntax documentation.
 
 # hw/alpha/pci.c
 alpha_pci_iack_write(void) ""
diff --git a/hw/arm/trace-events b/hw/arm/trace-events
index d0dad16..d5f33a2 100644
--- a/hw/arm/trace-events
+++ b/hw/arm/trace-events
@@ -1,4 +1,4 @@
-# See docs/trace-events.txt for syntax documentation.
+# See docs/tracing.txt for syntax documentation.
 
 # hw/arm/virt-acpi-build.c
 virt_acpi_setup(void) "No fw cfg or ACPI disabled. Bailing out."
diff --git a/hw/audio/trace-events b/hw/audio/trace-events
index 796f4a1..3210386 100644
--- a/hw/audio/trace-events
+++ b/hw/audio/trace-events
@@ -1,4 +1,4 @@
-# See docs/trace-events.txt for syntax documentation.
+# See docs/tracing.txt for syntax documentation.
 
 # hw/audio/cs4231.c
 cs4231_mem_readl_dreg(uint32_t reg, uint32_t ret) "read dreg %d: 0x%02x"
diff --git a/hw/block/trace-events b/hw/block/trace-events
index 31df44b..d0dd94f 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -1,4 +1,4 @@
-# See docs/trace-events.txt for syntax documentation.
+# See docs/tracing.txt for syntax documentation.
 
 # 

Re: [Qemu-devel] [PATCH v5 2/2] ACPI: Add -acpitable fadt= to allow FADT revision changes

2016-08-12 Thread Paolo Bonzini


On 11/08/2016 11:36, Lv Zheng wrote:
>  
> -error_setg(errp, "'-acpitable' requires one of 'data' or 'file'");
> +val = qemu_opt_get((QemuOpts *)opts, "fadt");
> +if (val) {
> +unsigned long rev;

Don't use qemu_opt_get.  Add the field to AcpiTableOptions in
qapi-schema.json, and then use hdrs->has_fadt, hdrs->fadt.

Paolo



[Qemu-devel] [PATCH for-2.7 1/4] virtio: recalculate vq->inuse after migration

2016-08-12 Thread Stefan Hajnoczi
The vq->inuse field is not migrated.  Many devices don't hold
VirtQueueElements across migration so it doesn't matter that vq->inuse
starts at 0 on the destination QEMU.

At least virtio-serial, virtio-blk, and virtio-balloon migrate while
holding VirtQueueElements.  For these devices we need to recalculate
vq->inuse upon load so the value is correct.

Signed-off-by: Stefan Hajnoczi 
---
 hw/virtio/virtio.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 15ee3a7..4df8274 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -1648,6 +1648,20 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f, int 
version_id)
 }
 vdev->vq[i].used_idx = vring_used_idx(>vq[i]);
 vdev->vq[i].shadow_avail_idx = vring_avail_idx(>vq[i]);
+
+/* Some devices migrate VirtQueueElements that have been popped
+ * from the avail ring but not yet returned to the used ring.
+ */
+vdev->vq[i].inuse = vdev->vq[i].last_avail_idx -
+vdev->vq[i].used_idx;
+if (vdev->vq[i].inuse > vdev->vq[i].vring.num) {
+error_report("VQ %d size 0x%x < last_avail_idx 0x%x - "
+ "used_idx 0x%x"
+ i, vdev->vq[i].vring.num,
+ vdev->vq[i].last_avail_idx,
+ vdev->vq[i].used_idx);
+return -1;
+}
 }
 }
 
-- 
2.7.4




Re: [Qemu-devel] [RFC v4 00/28] Base enabling patches for MTTCG

2016-08-12 Thread Alex Bennée

G 3  writes:

> On Aug 12, 2016, at 9:19 AM, Alex Bennée wrote:
>
>> On 11 August 2016 at 17:43, G 3  wrote:
>>>
>>> On Aug 11, 2016, at 11:24 AM, qemu-devel-requ...@nongnu.org wrote:
>>>
>>>
>>> Performance
>>>
>>> ===
>>>
>>>
>>> You can't do full work-load testing on this tree due to the lack of
>>>
>>> atomic support (but I will run some numbers on
>>>
>>> mttcg/base-patches-v4-with-cmpxchg-atomics-v2). However you certainly
>>>
>>> see a run time improvement with the kvm-unit-tests TCG group.
>>>
>>>
>>>   retry.py called with ['./run_tests.sh', '-t', '-g', 'tcg', '-o',
>>> '-accel
>>> tcg,thread=single']
>>>
>>>   run 1: ret=0 (PASS), time=1047.147924 (1/1)
>>>
>>>   run 2: ret=0 (PASS), time=1071.921204 (2/2)
>>>
>>>   run 3: ret=0 (PASS), time=1048.141600 (3/3)
>>>
>>>   Results summary:
>>>
>>>   0: 3 times (100.00%), avg time 1055.737 (196.70 varience/14.02
>>> deviation)
>>>
>>>   Ran command 3 times, 3 passes
>>>
>>>   retry.py called with ['./run_tests.sh', '-t', '-g', 'tcg', '-o',
>>> '-accel
>>> tcg,thread=multi']
>>>
>>>   run 1: ret=0 (PASS), time=303.074210 (1/1)
>>>
>>>   run 2: ret=0 (PASS), time=304.574991 (2/2)
>>>
>>>   run 3: ret=0 (PASS), time=303.327408 (3/3)
>>>
>>>   Results summary:
>>>
>>>   0: 3 times (100.00%), avg time 303.659 (0.65 varience/0.80
>>> deviation)
>>>
>>>   Ran command 3 times, 3 passes
>>>
>>>
>>> The TCG tests run with -smp 4 on my system. While the TCG tests are
>>>
>>> purely CPU bound they do exercise the hot and cold paths of TCG
>>>
>>> execution (especially when triggering SMC detection). However
>>> there is
>>>
>>> still a benefit even with a 50% overhead compared to the ideal 263
>>>
>>> second elapsed time.
>>>
>>>
>>> Alex
>>>
>>>
>>>
>>> Your tests results look very promising. It looks like you saw a 3x
>>> speed
>>> improvement over single threading. Excellent. I wonder what the
>>> numbers
>>> would be for a 22 core Xeon or 72 core Xeon Phi...
>>
>> Well the initial results look like they tail off but I need to test
>> on a more
>> capable machine. I'm going to package up the test case first so people
>> can easily
>> replicate the test.
>>
>>> Do you think you could some test with an x86 guest like Windows
>>> XP? There
>>> are plenty of benchmark tests for this platform. Video encoding,
>>> Youtube
>>> video playback, and number crunching programs' results would be very
>>> interesting to see.
>>
>> I don't have any Windows images to hand I'm afraid. Besides Windows
>> is a fairly
>> boring guest from this point of view because:
>>
>>   - it's x86, so why use TCG over KVM
>>   - QEMU TCG generally sucks at media bencmarks due to SIMD emulation
>
> Mac OS X host don't have a hypervisor that QEMU supports (VirtualBox
> isn't supported), so TCG is the only thing that can be used. Maybe a
> free x86 guest like Linux could be used?

Sounds like you have the kit for this test case. Let me know if the
branch boots your test images?

--
Alex Bennée



Re: [Qemu-devel] [PATCH v5 2/2] ACPI: Add -acpitable fadt= to allow FADT revision changes

2016-08-12 Thread Igor Mammedov
On Fri, 12 Aug 2016 00:47:04 +
"Zheng, Lv"  wrote:

> Hi, Igor
> 
> Thanks for the review.
> 
> > From: Igor Mammedov [mailto:imamm...@redhat.com]
> > Subject: Re: [PATCH v5 2/2] ACPI: Add -acpitable fadt= to allow FADT
> > revision changes
> > 
> > On Thu, 11 Aug 2016 17:36:45 +0800
> > Lv Zheng  wrote:
> >   
> > > This patch allows FADT to be built with different revisions. When the  
> > revision  
> > > is greater than 1.0, 64-bit address fields may also be filled.
> > >
> > > Note that FADT revision 2 has never been defined by the ACPI  
> > specification. So  
> > > this patch only adds an option -acpitable fadt= to allow revision 1,3,5 
> > > to  
> > be  
> > > configured by the users.
> > >
> > > 1. Tested by booting a linux image, the 64-bit addresses are correctly  
> > filled  
> > >in the dumped FADT.
> > > 2. Tested by booting a Windows image, no boot failure can be seen.  
> > 
> > series still doesn't say why do you need 64-bit addresses in FADT,
> > current Seabios/OVMF allocates tables below 4Gb and gpe/pm
> > register blocks are below 4gb as well so there is no point in
> > accepting theses patches and adding extra CLI options as these
> > patches do.  
> [Lv Zheng] 
> This patch is used by us to probe Windows FADT behavior.
> Current known behavior includes:
> 1. On x86, Windows requires BIOS to have 2 FADTs, 1 is in RSDT, and probably 
> is a v1 table, the other is in XSDT, and probably is a v3+ table.
RDST is not limited to rev 1 only
it can as easily reference v2/3/4/5/6 tables
differences between RSDT and XSDT is that the former is able to point
to tables located below 4G only.

> 2. v2 FADT never exists in the spec, it is used in very early years, by IA64 
> prototype machines.
> 3. If the FADT in RSDT takes effective, then Windows actually ignores 64-bit 
> GAS fields, but uses 32-bit register fields.
> But there are still many uncertainties:
> 1. What if the FADT in XSDT takes effective?
ACPI 6.0 spec says:
"An ACPI-compatible OS must use the XSDT if present."
hence XSDT referenced FADT must be used, but that's Windows
so I won't bet that it actually does what spec mandates.

> 2. What's the behavior on IA64/ARM platforms?
For ARM virt machine, QEMU currently provides ACPI 5.1 variant of FADT.

> If we could have an option here, we could continue the probing work, trying 
> every combination. 
> 
> Thus the original purpose of this commit is - probing de-facto standard 
> behavior.
What I'd suggest is try to bump up revision unconditionally to 5.1 (same as ARM)
so it would provide 64-bit fields although not really used by QEMU
and upstream it (provided it won't break anything).

As for probing part with 64-bit fields actually used,
I'd keep it out of tree as it doesn't make sense for upstream
QEMU to have it since all addresses are below 4Gb and it's not
going to change to keep compatibility with legacy OSes.

That would keep out of tree bits minimal and at the same time
reduce maintenance headache on QEMU side since it won't have
to maintain extra -acpitable option forever.

> 
> > 
> > If we'd ever need to bump FADT revision, I'd first try to increase it
> > unconditionally and test/see if it would not upset legacy guests
> > Windows starting from XP, RHEL4/5/6
> > If it works then these patches are not necessary,
> > (this approach worked  just fine for bumping up DSDT revision to 2
> > it would be possible to use 64-bit math in ASL/AML).
> > 
> > if it doesn't, I still won't do it this way but rather:
> >  - make new revision used by default
> >  - add compat property to piix4_pm/ich9-lpc to force legacy revision
> >  - turn on legacy revision for old machine types using added above
> > property
> > 
> > That way we won't regress existing setups as old machines will stay
> > the same and only new machine types will be affected. And users that
> > actually want to play with legacy revision on new machine types could
> > force it by using above property.
> >   
> [Lv Zheng] 
> But it seems the code in this commit contains useful stuffs for qemu.
> 
> As I said previously, it seems Windows requires 2 FADTs.
Windows boots just fine with 1 FADT so far.

I wonder, what Windows version does require 2 FADTs?

> So having a revision parameter for build_fadt() seems to be necessary.
> Because if qemu wants to increase FADT revision, qemu may do this in this way:
> 1. Invoke build_fadt() with revision 1, and put it into RSDT;
> 2. Invoke build_fadt() with latest revision, and put it into XSDT.
> Also we know latest revision FADT is useful, it contains reduced hardware 
> support.
> And some of new ACPI features rely this model.
providing revision number is not enough, each revision might have
its own FADT structure, and it would be a bunch of code to maintain
only to play and see if Windows is happy about it.
I'd keep that out of tree.

> So I'm sure that this commit contains useful stuffs for qemu to do future 
> extension.
> 
> But I 

Re: [Qemu-devel] [PATCH 5/7] nios2: Add periodic timer emulation

2016-08-12 Thread Marek Vasut
On 08/10/2016 12:30 PM, Dmitry Osipenko wrote:
> On 07.08.2016 23:27, Marek Vasut wrote:
>> On 07/30/2016 11:42 PM, Dmitry Osipenko wrote:
>>> Hello Marek,
>>
>> Hi!
>>
>> Sorry for the late reply, I got back from vacation only recently.
>>
>> I noticed that a lot of files in this patchset are under LGPLv2.1 , I
>> believe that needs fixing too, right ? I will talk to Chris about this
>> as he is the original author of most of these files.
>>
> 
> There are quite many files in QEMU licensed under LGPLv2.1, so it's probably 
> not
> an issue. I don't know for sure.

Looking through the code, you have a point. OK, I will leave it as-is
and I'll fix it if and only if it is mandatory.

>>> On 28.07.2016 15:27, Marek Vasut wrote:
 From: Chris Wulff 

 Add the Altera timer model.

>>>
>>> [snip]
>>>
 +static void timer_write(void *opaque, hwaddr addr,
 +uint64_t val64, unsigned int size)
 +{
 +AlteraTimer *t = opaque;
 +uint64_t tvalue;
 +uint32_t value = val64;
> 
> Why not to use "val64" directly? Or better to rename it to "value" and drop 
> this
> definition.

Done, thanks for spotting this.

 +uint32_t count = 0;
 +int irqState = timer_irq_state(t);
 +
 +addr >>= 2;
 +addr &= 0x7;
 +switch (addr) {
 +case R_STATUS:
 +/* Writing zero clears the timeout */
>>>
>>> Either "zero" or "clears" should be omitted here.
>>
>> You are really supposed to write zero into the register according to the
>> specification. Writing anything else is undefined.
>>
> 
> Okay, then is clearing TO bit on writing *any* value is a common behaviour?
> Mentioning it in the comment would help to avoid confusion.

Reworded to "/* The timeout bit is cleared by writing the status
register. */" .

 +t->regs[R_STATUS] &= ~STATUS_TO;
 +break;
 +
 +case R_CONTROL:
 +t->regs[R_CONTROL] = value & (CONTROL_ITO | CONTROL_CONT);
 +if ((value & CONTROL_START) &&
 +!(t->regs[R_STATUS] & STATUS_RUN)) {
 +ptimer_run(t->ptimer, 1);
>>>
>>> Starting to run with counter = 0 would cause immediate ptimer trigger, is 
>>> that a
>>> correct behaviour for that timer?
>>
>> I believe it is. If you start the timer with countdown register = 0, it
>> should trigger.
>>
> 
> It would be good to have it verified.

I don't have access to the hardware, CCing Juro, he should have it.

> Also, ptimer now supports "on the fly mode switch":
> 
> https://github.com/qemu/qemu/commit/869e92b5c392eb6b2c7b398b878c435442b8e9dd
> 
> ptimer_run(t->ptimer, !(value & CONTROL_CONT)) could be used here and "manual"
> re-run dropped from the timer_hit() handler.

So who will re-run the timer if it's configured in the continuous mode
if it's not re-run in the timer_hit() ?

>>> FYI, I'm proposing ptimer policy feature that would help handling such edge
>>> cases correctly:
>>>
>>> https://lists.nongnu.org/archive/html/qemu-devel/2016-07/msg05044.html
>>>
>>> According to the "Nios Timer" datasheet, at least "wraparound after one 
>>> period"
>>> policy would be suited well for that timer.
>>
>> Yes, the timer api in qemu is pretty hard to grasp, I had trouble with
>> it so it is possible there are bugs in here.
>>
> 
> That would be very churny to implement with the current ptimer. Hopefully,
> ptimer policy would get into the QEMU and then it could be applied to this
> timer. So, I think it is fine for now.

Thanks for pointing it out, I'll keep an eye on it.

 +t->regs[R_STATUS] |= STATUS_RUN;
 +}
 +if ((value & CONTROL_STOP) && (t->regs[R_STATUS] & STATUS_RUN)) {
 +ptimer_stop(t->ptimer);
 +t->regs[R_STATUS] &= ~STATUS_RUN;
 +}
 +break;
 +
 +case R_PERIODL:
 +case R_PERIODH:
 +t->regs[addr] = value & 0x;
 +if (t->regs[R_STATUS] & STATUS_RUN) {
 +ptimer_stop(t->ptimer);
 +t->regs[R_STATUS] &= ~STATUS_RUN;
 +}
 +tvalue = (t->regs[R_PERIODH] << 16) | t->regs[R_PERIODL];
 +ptimer_set_limit(t->ptimer, tvalue + 1, 1);
 +break;
 +
 +case R_SNAPL:
 +case R_SNAPH:
 +count = ptimer_get_count(t->ptimer);
 +t->regs[R_SNAPL] = count & 0x;
 +t->regs[R_SNAPH] = (count >> 16) & 0x;
>>>
>>> "& 0x" isn't needed for the R_SNAPH.
>>
>> It isn't, until someone changes the storage type to something else but
>> uint32_t , which could happen with these sorts of systems -- the nios2
>> is a softcore (in an FPGA), so it can be adjusted if needed be. I can
>> drop this if you prefer that though.
>>
> 
> In case of the reduced register capacity, the ptimer limit would provide 
> correct
> "high" register value. In case of the expanded register capacity, the shift
> value 

  1   2   >