[Qemu-devel] [PATCH v5 04/12] tests: Add vm test lib

2017-08-31 Thread Fam Zheng
This is the common code to implement a "VM test" to 1) Download and initialize a pre-defined VM that has necessary dependencies to build QEMU and SSH access. 2) Archive $SRC_PATH to a .tar file. 3) Boot the VM, and pass the source tar file to the guest. 4) SSH into the VM, untar the

Re: [Qemu-devel] [PATCH v1 08/11] s390x: allow only 1 CPU with TCG

2017-08-31 Thread Cornelia Huck
On Wed, 30 Aug 2017 21:06:55 +0200 Thomas Huth wrote: > On 30.08.2017 19:05, David Hildenbrand wrote: > > Specifying more than 1 CPU (e.g. -smp 5) leads to SIGP errors (the > > guest tries to bring these CPUs up but fails), because we don't support > > multiple CPUs on s390x

[Qemu-devel] [PATCH 1/1] ppc: spapr: Move VCPU ID calculation into sPAPR

2017-08-31 Thread Sam Bobroff
Move the calculation of a CPU's VCPU ID out of the generic PPC code (ppc_cpu_realizefn()) and into sPAPR specific code (spapr_cpu_core_realize()) where it belongs. Unfortunately, due to the way things are ordered, we still need to default the VCPU ID in ppc_cpu_realizfn() but at least doing that

Re: [Qemu-devel] [PATCH 1/9] s390x/css: fix cc handling for XSCH

2017-08-31 Thread Cornelia Huck
On Thu, 31 Aug 2017 07:51:17 +0200 Thomas Huth wrote: > On 30.08.2017 18:36, Halil Pasic wrote: > > The function ioinst_handle_xsch is presenting cc 2 when it's supposed to > > present cc 1 and the other way around, because css_do_xsch has the error > > codes mixed up. Fixing

Re: [Qemu-devel] [PATCH] scripts: Support building with Python 3

2017-08-31 Thread Markus Armbruster
Stefan Hajnoczi writes: > On Mon, Aug 21, 2017 at 04:29:44PM +0200, Markus Armbruster wrote: >> What is our Python 2 -> 3 migration strategy? >> >> Don't support Python 3 until a flag day, then flip and don't support >> Python 2? > > Add support for Python 3 so that both

Re: [Qemu-devel] [PATCH 3/9] s390x/css: be more consistent if broken beyond repair

2017-08-31 Thread Thomas Huth
On 30.08.2017 18:36, Halil Pasic wrote: > If we detect that the internally manged state of the subchannel > is broken beyond repair while in do_subchannel_work in case of > virtual we just abort the operation and pretend all went well, > while in case of pass-through we honor the situation with

<    1   2   3   4