[Qemu-devel] [PATCH 0/2] Add missing attributions to hvf:

2018-01-23 Thread Izik Eidus
The following 2 patch's add a missing attributions to the hvf code




[Qemu-devel] [PATCH 2/2] ept_emulation_fault() need NetApp BSD attribution:

2018-01-23 Thread Izik Eidus
Moving it to a new file and add the BSD license there.

Signed-off-by: Izik Eidus 
---
 target/i386/hvf/ept_fault.h | 70 +
 target/i386/hvf/hvf.c   | 38 +---
 2 files changed, 71 insertions(+), 37 deletions(-)
 create mode 100644 target/i386/hvf/ept_fault.h

diff --git a/target/i386/hvf/ept_fault.h b/target/i386/hvf/ept_fault.h
new file mode 100644
index 00..c2938d2bd4
--- /dev/null
+++ b/target/i386/hvf/ept_fault.h
@@ -0,0 +1,70 @@
+/*-
+ * Copyright (c) 2011 NetApp, Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY NETAPP, INC ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL NETAPP, INC OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#ifndef EPT_FAULT_H
+#define EPT_FAULT_H
+
+#include "hvf-i386.h"
+
+static inline bool ept_emulation_fault(hvf_slot *slot, uint64_t gpa, uint64_t 
ept_qual)
+{
+int read, write;
+
+/* EPT fault on an instruction fetch doesn't make sense here */
+if (ept_qual & EPT_VIOLATION_INST_FETCH) {
+return false;
+}
+
+/* EPT fault must be a read fault or a write fault */
+read = ept_qual & EPT_VIOLATION_DATA_READ ? 1 : 0;
+write = ept_qual & EPT_VIOLATION_DATA_WRITE ? 1 : 0;
+if ((read | write) == 0) {
+return false;
+}
+
+if (write && slot) {
+if (slot->flags & HVF_SLOT_LOG) {
+memory_region_set_dirty(slot->region, gpa - slot->start, 1);
+hv_vm_protect((hv_gpaddr_t)slot->start, (size_t)slot->size,
+  HV_MEMORY_READ | HV_MEMORY_WRITE);
+}
+}
+
+/*
+ * The EPT violation must have been caused by accessing a
+ * guest-physical address that is a translation of a guest-linear
+ * address.
+ */
+if ((ept_qual & EPT_VIOLATION_GLA_VALID) == 0 ||
+(ept_qual & EPT_VIOLATION_XLAT_VALID) == 0) {
+return false;
+}
+
+return !slot;
+}
+
+
+#endif
diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
index ab4820c3f5..94d8d119d5 100644
--- a/target/i386/hvf/hvf.c
+++ b/target/i386/hvf/hvf.c
@@ -36,6 +36,7 @@
 #include "x86_emu.h"
 #include "x86_task.h"
 #include "x86hvf.h"
+#include "ept_fault.h"
 
 #include 
 #include 
@@ -292,43 +293,6 @@ void hvf_cpu_synchronize_post_init(CPUState *cpu_state)
 run_on_cpu(cpu_state, _hvf_cpu_synchronize_post_init, RUN_ON_CPU_NULL);
 }
 
-static bool ept_emulation_fault(hvf_slot *slot, uint64_t gpa, uint64_t 
ept_qual)
-{
-int read, write;
-
-/* EPT fault on an instruction fetch doesn't make sense here */
-if (ept_qual & EPT_VIOLATION_INST_FETCH) {
-return false;
-}
-
-/* EPT fault must be a read fault or a write fault */
-read = ept_qual & EPT_VIOLATION_DATA_READ ? 1 : 0;
-write = ept_qual & EPT_VIOLATION_DATA_WRITE ? 1 : 0;
-if ((read | write) == 0) {
-return false;
-}
-
-if (write && slot) {
-if (slot->flags & HVF_SLOT_LOG) {
-memory_region_set_dirty(slot->region, gpa - slot->start, 1);
-hv_vm_protect((hv_gpaddr_t)slot->start, (size_t)slot->size,
-  HV_MEMORY_READ | HV_MEMORY_WRITE);
-}
-}
-
-/*
- * The EPT violation must have been caused by accessing a
- * guest-physical address that is a translation of a guest-linear
- * address.
- */
-if ((ept_qual & EPT_VIOLATION_GLA_VALID) == 0 ||
-(ept_qual & EPT_VIOLATION_XLAT_VALID) == 0) {
-return false;
-}
-
-return !slot;
-}
-
 static void hvf_set_dirty_tracking(MemoryRegionSection *section, bool on)
 {
 hvf_slot *slot;
-- 
2.13.6 (Apple Git-96)




[Qemu-devel] [PATCH 1/2] Add missing hvdos public domain attribution:

2018-01-23 Thread Izik Eidus
hvf.c and vmx.h contain code from hvdos.c that is released as public domain:

from hvdos github: https://github.com/mist64/hvdos

"License

See LICENSE.txt (2-clause-BSD).

In order to simplify use of this code as a template, you can consider any parts 
from "hvdos.c" and "interface.h" as being in the public domain."

Signed-off-by: Izik Eidus 
---
 target/i386/hvf/hvf.c | 3 +++
 target/i386/hvf/vmx.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
index 010866ed22..ab4820c3f5 100644
--- a/target/i386/hvf/hvf.c
+++ b/target/i386/hvf/hvf.c
@@ -17,6 +17,9 @@
  *
  * You should have received a copy of the GNU Lesser General Public
  * License along with this program; if not, see .
+ *
+ * This file contain code under public domain from the hvdos project:
+ * https://github.com/mist64/hvdos
  */
 #include "qemu/osdep.h"
 #include "qemu-common.h"
diff --git a/target/i386/hvf/vmx.h b/target/i386/hvf/vmx.h
index 9dfcd2f2eb..162a7d51ae 100644
--- a/target/i386/hvf/vmx.h
+++ b/target/i386/hvf/vmx.h
@@ -17,6 +17,9 @@
  *
  * You should have received a copy of the GNU Lesser General Public
  * License along with this program; if not, see .
+ *
+ * This file contain code under public domain from the hvdos project:
+ * https://github.com/mist64/hvdos
  */
 
 #ifndef VMX_H
-- 
2.13.6 (Apple Git-96)




Re: [Qemu-devel] virtio block device is not working

2018-01-23 Thread joserz
On Tue, Jan 23, 2018 at 01:05:28AM -0200, jos...@linux.vnet.ibm.com wrote:
> Hello people!
> 
> I'm not able to boot any guest that sets a virtio block device like:
> (branch master)
> 
> [PPC64]
> qemu-system-ppc64 -cpu POWER8 -nographic -vga none -m 4G -M 
> pseries,accel=kvm,kvm-type=PR -drive file=disk.qcow2,if=virtio

my bad, actually the command line is:

qemu-system-ppc64 -cpu POWER8 -nographic -vga none -m 4G -M pseries,accel=kvm 
-netdev type=user,id=net0 -device virtio-net-pci,netdev=net0 -drive 
file=../disk.qcow2,if=virtio

and the problem seem to be in virtio-net-pci, not in the block device


> QEMU Starting
>  Build Date = Dec 18 2017 13:08:00
>  FW Version = git-fa981320a1e0968d
>  Press "s" to enter Open Firmware.
> 
> Populating /vdevice methods
> Populating /vdevice/vty@7100
> Populating /vdevice/nvram@7101
> Populating /vdevice/v-scsi@7102
>SCSI: Looking for devices
>   8200 CD-ROM   : "QEMU QEMU CD-ROM  2.5+"
> Populating /pci@8002000
>  00  (D) : 1af4 1000virtio [ net ]
> Aborted
> 
> [x86]
> 
> qemu-system-x86_64 -m 4G -enable-kvm -drive file=util.qcow2,if=virtio
> Running QEMU with GTK 2.x is deprecated, and will be removed
> in a future release. Please switch to GTK 3.x instead
> [1]5282 abort
> 
> [Cause]
> 
> The commit 4fe6d78b2e introduces the
> 
> ...
> kvm_mem_ioeventfd_del(...) {
> ...
> r = kvm_set_ioeventfd_mmio(fd, ...
> if (r < 0) {
> abort();
> }
> 
> +if (e->cleanup) {
> +e->cleanup(e);
> +}
> }
> 
> For some reason, not yet clear to me, cleanup() calls the same
> kvm_mem_ioeventfd_del again and again until kvm_set_ioeventfd_mmio
> returns < 0 and abort().
> 
> I was going to send a patch to revert that 'if ()' but I think it could
> cause a regression. What do you guys think?
> 
> Thanks,
> 
> Jose Ricardo Ziviani
> 
> 




Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

2018-01-23 Thread bzt bzt
On Tue, Jan 23, 2018 at 12:22 PM, Peter Maydell 
wrote:

> On 23 January 2018 at 11:13, bzt bzt  wrote:
> > There's a huge misunderstanding here. I have a working qemu for about
> half a
> > year now, and I don't need it merged. It's not my goal to submit a patch
> to
> > qemu in any way, I just did that because I had modified an Open Source
> > software and wanted to share it with the community. If you don't merge my
> > patch, I don't care. Other users will.
>
> Unfortunately we legally can't merge your patch (even if somebody
> else is willing to do the work of cleaning it up) because you
> haven't provided a signed-off-by line...
>

You have to came up with a better excuse for your incompetence.

Date: Sun, 22 Oct 2017 14:59:20 +0200
Subject: [PATCH] BCM2837 and machine raspi3

Signed-off-by: bzt 

And no, I don't feel bad at all about not letting you take advantage on my
programming skills. Now you're on your own, when users starts to demand
raspi3 support in qemu don't expect me to help.

Have a nice day,
bzt


>
> thanks
> -- PMM
>


Re: [Qemu-devel] [RFC PATCH qemu] qmp: Add qom-list-properties to list QOM object properties

2018-01-23 Thread Andrea Bolognani
On Tue, 2018-01-23 at 22:20 +1100, David Gibson wrote:
> > David, I know you're busy with linux.conf.au, but it would be
> > really helpful if you could carve out five minutes to look over
> > Alexey's proposal again, with my reply above in mind, and let us
> > know whether it looks a reasonable design. Doesn't have to be a
> > review, just a quick feedback on the high-level idea.
> 
> It looks ok, I think, but I don't think I'm really the right person to
> ask.  I do wonder if creating a throwaway instance could cause
> trouble, especially for something like machine that might well have
> gotten away with having global side-effects in the past.  I think we
> need to talk with someone who knows more about qom and qapi - Markus
> seems the obvious choice.

Good point. CC'ing Markus to try and grab his attention :)

-- 
Andrea Bolognani / Red Hat / Virtualization



Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures

2018-01-23 Thread Alex Bennée

Peter Maydell  writes:

> On 18 January 2018 at 14:59, Philippe Mathieu-Daudé  wrote:
>> My comment was for a previous line:
>>
>>   uint64_t frac   : 64;
>>
>> I don't have enough compiler knowledge to be sure how this bitfield is
>> interpreted by the compiler. I understood the standard as bitfields are
>> for 'unsigned', and for IL32 we have sizeof(unsigned) = 32, so I wonder
>> how a :64 bitfield ends (bits >= 32 silently truncated?).
>
> Defining a 64-bit bitfield is a bit pointless (why not just use
> uint64_t?) but there's nothing particularly different for IL32P64 here.
> The spec says the underlying type is _Bool, signed int, unsigned
> into, or an implementation defined type. For QEMU's hosts 'int'
> is always 32 bits, so if gcc and clang allow bitfields on a
> 64-bit type like uint64_t (as an impdef extension) then they
> should work on all hosts. (In any case it needs to either work
> or give a compiler error, silent truncation isn't an option.)

Using explicit size types and an attribute on FloatClass seemed to be
enough:

/*
 * Classify a floating point number. Everything above float_class_qnan
 * is a NaN so cls >= float_class_qnan is any NaN.
 */

typedef enum __attribute__ ((__packed__)) {
float_class_unclassified,
float_class_zero,
float_class_normal,
float_class_inf,
float_class_qnan,  /* all NaNs from here */
float_class_snan,
float_class_dnan,
float_class_msnan, /* maybe silenced */
} FloatClass;

/*
 * Structure holding all of the decomposed parts of a float. The
 * exponent is unbiased and the fraction is normalized. All
 * calculations are done with a 64 bit fraction and then rounded as
 * appropriate for the final format.
 *
 * Thanks to the packed FloatClass a decent compiler should be able to
 * fit the whole structure into registers and avoid using the stack
 * for parameter passing.
 */

typedef struct {
uint64_t frac;
int32_t  exp;
FloatClass cls;
bool sign;
} FloatParts;

--
Alex Bennée



Re: [Qemu-devel] vhost-pci and virtio-vhost-user

2018-01-23 Thread Stefan Hajnoczi
On Mon, Jan 22, 2018 at 11:54:41AM +0800, Jason Wang wrote:
> On 2018年01月20日 01:20, Stefan Hajnoczi wrote:
> > > I don't propose any new idea. I just want to know what's the advantage of
> > > vhost-pci over zerocopy. Both needs one time of copy, the difference is 
> > > the
> > > vhost-pci did it inside a guest but zerocopy did in on host.
> > Exitless VM2VM communication is desirable if you cannot run software on
> > the host or if both endpoints are already in VMs.  In that case running
> > one thing in a VM and another on the host doesn't make sense.
> 
> Well, I must have missed anything, I don't see why we can not run virtio-net
> backend on host. Especially it only does L2 stuffs, higher level of service
> could be provided by another VM for sure. So it looks to me
> virtio-vhost-user is just a split device implementation which is irreverent
> to the service it could provide.
> 
> Maybe you can provide a concrete examples of virtio-vhost-user and its
> advantages?
[...]
> > 
> > The obvious environment where this applies is in the cloud where
> > everything is a VM.
> 
> So a typical setup makes the VMs can already talk to each other through
> ethernet(virtio-net). Virtio-vhost-user looks much less flexible than exist
> stuffs. The only possible advantage of virtio-vhost-user is its performance
> or security which still need to be proved.

I look forward to performance results but in the meantime consider
existing vhost-user use cases.  Those applications could just use
network communication too (e.g. iSCSI instead of vhost-user-scsi).  They
choose vhost-user mainly because it's faster (zerocopy, no vmexits, and
no network protocol overhead).

There are other advantages too.  In the iSCSI case, guests need
configuration details to establish the iSCSI connection.  In the
virtio-scsi case the guests only need the virtio-scsi driver and no
configuration to access the LUNs.  It's simpler on the guest side!

So the reasons for virtio-vhost-user are the same as vhost-user PLUS
some users choose to deploy everything in VMs and cannot run host
userspace process.

Stefan


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

2018-01-23 Thread bzt bzt
Hi,

On Mon, Jan 22, 2018 at 1:12 PM, Peter Maydell 
wrote:

> On 18 January 2018 at 21:39, bzt bzt  wrote:
> > Dear All,
> >
> > Since you still haven't merged Alistair's patch, I decided to include it
> in
> > my own.
> > I've shrinked the number of modified files to two, that's the bare
> minimum
> > to support "-M raspi3" switch. Bcm2836.c modified minimally, the rest is
> in
> > raspi.c. I've renamed raspi2_init() to raspi_init() 'cos now it
> initializes
> > raspi3 as well, no additional function.
> >
>
> Can you send this as a proper patch email, not as a reply to
> an existing email thread, please? (This makes our automated tooling
> much happier.)
>

Only if you're not demanding any further nonsense modifications.


>
> In particular we can't apply patches if they don't come with
> the right Signed-off-by: lines from everybody who contributed
> code to them.
>
> I've made some code review comments below.
>
> > diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
> > index 8c43291112..5119e00051 100644
> > --- a/hw/arm/bcm2836.c
> > +++ b/hw/arm/bcm2836.c
> > @@ -15,6 +15,7 @@
> >  #include "hw/arm/bcm2836.h"
> >  #include "hw/arm/raspi_platform.h"
> >  #include "hw/sysbus.h"
> > +#include "hw/boards.h"
> >  #include "exec/address-spaces.h"
> >
> >  /* Peripheral base address seen by the CPU */
> > @@ -30,7 +31,7 @@ static void bcm2836_init(Object *obj)
> >
> >  for (n = 0; n < BCM2836_NCPUS; n++) {
> >  object_initialize(&s->cpus[n], sizeof(s->cpus[n]),
> > -  "cortex-a15-" TYPE_ARM_CPU);
> > +  current_machine->cpu_type);
>
> This SoC code shouldn't be looking at the current_machine settings.
> It should have a QOM property that specifies the cpu type, and

the raspi.c code should set that property. (Call the property
>
'cpu-type' -- if you grep in hw/arm for that string you'll find
> some examples of existing devices/boards that do this.)
>

I'll give you some time to think about why it is nonsense that you asking
for.
Hint: you cannot add properties to an uninitialized object, you can't add
the CPUs in the realize phase (will cause segfaults, I've tried) and SoC
initialization will do call bcm2836_init().

  [...]

> There should be more spaces in this : "version == 3 ? ...".
> If you run your patch through scripts/checkpatch.pl it should
> help with this kind of style nit (though it doesn't always find
> everything and sometimes it gets confused, so it's not always right).
>

Sure thing.


> [...]
> This will get confused if the user passes a -cpu argument. Instead
> we should just have the machine type directly determine the version.
> There are several ways to do this, but the simplest way is to have
> raspi2_machine_init() set mc->init to raspi2_init() and
> raspi3_machine_init()
> set mc->niit to raspi3_init(), and thenthose function calls
> raspi_init(machine, 2) or raspi_init(machine, 3).
>

Auch. Originally there were two raspi_init() functions (with two different
version values), I've reduced the number to one because you asked for it.
I've also tried to access the MachineClass object from raspi_init(), but
it's impossible, MACHINE_CLASS() drops and assert, find_machine_class()
segfaults. Nice model interface you have there.


>
> (The other approach would be to make the board set up a subclass
> of MachineState and then have raspi2 and raspi3 be subclasses of
> that, which gives you a place to define raspi-specific data fields
> like "version". You can see that approach in hw/arm/vexpress.c. But
> that seems like a lot of effort to go to given where we've started,
> so I don't really recommend it.)
>

Again, that is EXACTLY what I originally had, and you (the maintainers)
said there shouldn't be a new BCM2837 class, so I've removed it.
Look, if you can't understand how my patch works, just say so, no shame in
that.


> [...]
>
> I don't want to add new machine types which set the
> ignore_memory_transaction_failures flag to true -- this is
> only for existing board models where we don't know what
> guest code that used to run would break when the flag was
> flipped. For new boards we know that no code runs on them
> so can leave the flag at its correct default.
>

Just copy'n'pasted raspi2, only modified the CPU model in which they differ.


>
> This may mean that you need to add some extra dummy
> devices to the the SoC model using
> create_unimplemented_device() so that your guest image
> doesn't crash trying to probe those devices.
>

This may mean your users will be very upset because mainline qemu won't
emulate raspi3 in the foreseeable future, because it's sure like hell I
won't fix something that's not broken.


>
> I appreciate that this is a bit annoying for a case like this
> where it's adding a new variant of an existing SoC, but
> this is one of the situations where the only practical
> opportunity to get the implementation right without breaking
> existing QEMU users is at the point where we add the new
> board model

Re: [Qemu-devel] [PATCH v3 2/5] target/arm: Add predicate registers for SVE

2018-01-23 Thread Alex Bennée

Richard Henderson  writes:

> Signed-off-by: Richard Henderson 

Reviewed-by: Alex Bennée 

> ---
>  target/arm/cpu.h | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 1854fe51a8..3f4f6b6144 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -188,6 +188,13 @@ typedef struct ARMVectorReg {
>  uint64_t d[2 * ARM_MAX_VQ] QEMU_ALIGNED(16);
>  } ARMVectorReg;
>
> +/* In AArch32 mode, predicate registers do not exist at all.  */
> +#ifdef TARGET_AARCH64
> +typedef struct ARMPredicateReg {
> +uint64_t p[2 * ARM_MAX_VQ / 8] QEMU_ALIGNED(16);
> +} ARMPredicateReg;
> +#endif
> +
>
>  typedef struct CPUARMState {
>  /* Regs for current mode.  */
> @@ -515,6 +522,11 @@ typedef struct CPUARMState {
>  struct {
>  ARMVectorReg zregs[32];
>
> +#ifdef TARGET_AARCH64
> +/* Store FFR as pregs[16] to make it easier to treat as any other.  
> */
> +ARMPredicateReg pregs[17];
> +#endif
> +
>  uint32_t xregs[16];
>  /* We store these fpcsr fields separately for convenience.  */
>  int vec_len;


--
Alex Bennée



[Qemu-devel] [PATCH] 9pfs: Correctly handle cancelled requests

2018-01-23 Thread Greg Kurz
From: Keno Fischer 

# Background

I was investigating spurious non-deterministic EINTR returns from
various 9p file system operations in a Linux guest served from the
qemu 9p server.

 ## EINTR, ERESTARTSYS and the linux kernel

When a signal arrives that the Linux kernel needs to deliver to user-space
while a given thread is blocked (in the 9p case waiting for a reply to its
request in 9p_client_rpc -> wait_event_interruptible), it asks whatever
driver is currently running to abort its current operation (in the 9p case
causing the submission of a TFLUSH message) and return to user space.
In these situations, the error message reported is generally ERESTARTSYS.
If the userspace processes specified SA_RESTART, this means that the
system call will get restarted upon completion of the signal handler
delivery (assuming the signal handler doesn't modify the process state
in complicated ways not relevant here). If SA_RESTART is not specified,
ERESTARTSYS gets translated to EINTR and user space is expected to handle
the restart itself.

 ## The 9p TFLUSH command

The 9p TFLUSH commands requests that the server abort an ongoing operation.
The man page [1] specifies:

```
If it recognizes oldtag as the tag of a pending transaction, it should abort any
pending response and discard that tag.
[...]
When the client sends a Tflush, it must wait to receive the corresponding Rflush
before reusing oldtag for subsequent messages. If a response to the flushed 
request
is received before the Rflush, the client must honor the response as if it had 
not
been flushed, since the completed request may signify a state change in the 
server
```

In particular, this means that the server must not send a reply with the orignal
tag in response to the cancellation request, because the client is obligated
to interpret such a reply as a coincidental reply to the original request.

 # The bug

When qemu receives a TFlush request, it sets the `cancelled` flag on the 
relevant
pdu. This flag is periodically checked, e.g. in `v9fs_co_name_to_path`, and if
set, the operation is aborted and the error is set to EINTR. However, the server
then violates the spec, by returning to the client an Rerror response, rather
than discarding the message entirely. As a result, the client is required
to assume that said Rerror response is a result of the original request, not
a result of the cancellation and thus passes the EINTR error back to user space.
This is not the worst thing it could do, however as discussed above, the correct
error code would have been ERESTARTSYS, such that user space programs with
SA_RESTART set get correctly restarted upon completion of the signal handler.
Instead, such programs get spurious EINTR results that they were not expecting
to handle.

It should be noted that there are plenty of user space programs that do not
set SA_RESTART and do not correctly handle EINTR either. However, that is then
a userspace bug. It should also be noted that this bug has been mitigated by
a recent commit to the Linux kernel [2], which essentially prevents the kernel
from sending Tflush requests unless the process is about to die (in which case
the process likely doesn't care about the response). Nevertheless, for older
kernels and to comply with the spec, I believe this change is beneficial.

 # Implementation

The fix is fairly simple, just skipping notification of a reply if
the pdu was previously cancelled. We do however, also notify the transport
layer that we're doing this, so it can clean up any resources it may be
holding. I also added a new trace event to distinguish
operations that caused an error reply from those that were cancelled.

One complication is that we only omit sending the message on EINTR errors in
order to avoid confusing the rest of the code (which may assume that a
client knows about a fid if it sucessfully passed it off to pud_complete
without checking for cancellation status). This does mean that if the server
acts upon the cancellation flag, it always needs to set err to EINTR. I believe
this is true of the current code.

[1] https://9fans.github.io/plan9port/man/man9/flush.html
[2] 
https://github.com/torvalds/linux/commit/9523feac272ccad2ad8186ba4fcc89103754de52

Signed-off-by: Keno Fischer 
Reviewed-by: Greg Kurz 
[groug, send a zero-sized reply instead of detaching the buffer]
Signed-off-by: Greg Kurz 
---

To be effective, a patch is needed for the 9pnet_virtio driver in Linux as
well:

https://sourceforge.net/p/v9fs/mailman/message/36200555/


Stefano,

As you suggested, the right thing to do is indeed to inform the transport
layer that the request was consumed, even if we don't send a 9p reply to
the client (MST suggested the same for the kernel-side patches I had sent
a month ago on the v9fs-developper list).

So in the end the following patch is not needed:

http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg00175.html

Zeroing the PDU size before pushing it back does job for virtio, and
it seems it w

Re: [Qemu-devel] [PATCH v2 8/8] qapi: query-blockstat: add driver specific file-posix stats

2018-01-23 Thread Anton Nefedov



On 22/1/2018 11:55 PM, Eric Blake wrote:

On 01/19/2018 06:50 AM, Anton Nefedov wrote:

A block driver can provide a callback to report driver-specific
statistics.

file-posix driver now reports discard statistics

Signed-off-by: Anton Nefedov 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---



+++ b/qapi/block-core.json
@@ -774,6 +774,40 @@
 'timed_stats': ['BlockDeviceTimedStats'] } }
  
  ##

+# @BlockDriverStatsFile:
+#
+# File driver statistics
+#
+# @discard_nb_ok: The number of succeeded discard operations performed by
+# the driver.
+#
+# @discard_nb_failed: The number of failed discard operations performed by
+# the driver.
+#
+# @discard_bytes_ok: The number of bytes discarded by the driver.
+#
+# Since 2.12
+##
+{ 'struct': 'BlockDriverStatsFile',
+  'data': {
+  'discard_nb_ok': 'int',
+  'discard_nb_failed': 'int',
+  'discard_bytes_ok': 'int'
+  } }


New interfaces should prefer '-' over '_', where possible (a reason for
using '_' is if the fields are alongside pre-existing fields that
already used '_').  Let's see how this gets used...[1]


+
+##
+# @BlockDriverStats:
+#
+# Statistics of a block driver (driver-specific)
+#
+# Since: 2.12
+##
+{ 'union': 'BlockDriverStats',
+  'data': {
+  'file': 'BlockDriverStatsFile'
+  } }


Markus has been adamant that we add no new "simple unions" (unions with
a 'discriminator' field) - because they are anything but simple in the
long run.


+
+##
  # @BlockStats:
  #
  # Statistics of a virtual block device or a block backing device.
@@ -785,6 +819,8 @@
  #
  # @stats:  A @BlockDeviceStats for the device.
  #
+# @driver-stats: Optional driver-specific statistics. (Since 2.12)
+#
  # @parent: This describes the file block device if it has one.
  #  Contains recursively the statistics of the underlying
  #  protocol (e.g. the host file for a qcow2 image). If there is
@@ -798,6 +834,7 @@
  { 'struct': 'BlockStats',
'data': {'*device': 'str', '*node-name': 'str',
 'stats': 'BlockDeviceStats',
+   '*driver-stats': 'BlockDriverStats',


...[1] You are using it alongside a struct that already uses '-'
(node-name), so you should use dashes.

So, the difference between your proposal (a simple union) and using a
"flat union", on the wire, is yours:

"return": { ..., "driver-stats": { "type": "file", "data": {
"discard_nb_ok: ... } } }

vs. a flat union:

"return": { ..., "driver-stats": { "driver": "file", "discard-nb-ok":
... } }

where you can benefit from less nesting and a saner discriminator name.



Right, forgot about those unions.. Will fix.

(I guess I will need an extra enum, like BlockdevDriverWithStats with a
single 'file' member, otherwise it seems to require to define data for
each BlockdevDriver type)

/Anton



[Qemu-devel] savevm snapshot

2018-01-23 Thread sridhar kulkarni via Qemu-devel
I am working on creating a snapshot for ARM based VM running on A7. We don't 
use disk images, so to save the snapshot I am passing "-drive if=none, 
format=qcow2, file=/home/sridhar/qemu_disk_images/dummy.qcow2" as dummy disk to 
save the snapshot.
Then from qemu monitor, I run the "savevm" command. The savevm seems to execute 
and return, however I don't see the RAM being copied correctly, and loadvm 
fails to restore the VM state.
When I debugged, I can see that in "ram_control_save_page", the condition 
highlighted  in bold below fails and function returns RAM_SAVE_CONTROL_NOT_SUPP.
Am I missing something here? From the documents available on qemu.org, I can 
see that savevm should take care of saving RAM contents as well, and it should 
work seamlessly.
Can you help on this?
-Sridhar

| size_t ram_control_save_page(QEMUFile *f, ram_addr_t block_offset, |
|  |  ram_addr_t offset, size_t size, |
|  |  uint64_t *bytes_sent) |
|  | { |
|  |   if (f->hooks && f->hooks->save_page) { |
|  |  int ret = f->hooks->save_page(f, f->opaque, block_offset, |
|  |  offset, size, bytes_sent); |
|  |  |
|  |  if (ret != RAM_SAVE_CONTROL_DELAYED) { |
|  |  if (bytes_sent && *bytes_sent > 0) { |
|  |  qemu_update_position(f, *bytes_sent); |
|  |  } else if (ret < 0) { |
|  |  qemu_file_set_error(f, ret); |
|  |  } |
|  |  } |
|  |  |
|  |  return ret; |
|  |  } |
|  |  |
|  |  return RAM_SAVE_CONTROL_NOT_SUPP; |
|  | } |



Re: [Qemu-devel] [RFC PATCH qemu] qmp: Add qom-list-properties to list QOM object properties

2018-01-23 Thread David Gibson
On Tue, Jan 23, 2018 at 11:08:31AM +0100, Andrea Bolognani wrote:
> On Fri, 2018-01-19 at 15:34 +0100, Andrea Bolognani wrote:
> > > > This won't solve the libvirt problem we were discussing, because it
> > > > needs an existing instance of the object.  libvirt wants to know the
> > > > machine properties *without* instantiating an instance.
> > > 
> > > My patch works with types, it creates an instance for a short time itself,
> > > this is why it does not do a thing for "pseries" as it is not a type and
> > > prints properties for the "pseries-2.12-machine" type.
> > 
> > Yeah, I took this for a spin and can confirm that it's pretty much
> > exactly what I was thinking about. The fact that the QMP command
> > instantiates objects behind the scenes is not an issue, at least
> > from libvirt's point of view: device-list-properties does the same
> > thing and we already use it quite happily; what matters is that we
> > can call this, along with all the other capabilities-collecting
> > QMP commands, in one go and on a single QEMU instance.
> 
> David, I know you're busy with linux.conf.au, but it would be
> really helpful if you could carve out five minutes to look over
> Alexey's proposal again, with my reply above in mind, and let us
> know whether it looks a reasonable design. Doesn't have to be a
> review, just a quick feedback on the high-level idea.

It looks ok, I think, but I don't think I'm really the right person to
ask.  I do wonder if creating a throwaway instance could cause
trouble, especially for something like machine that might well have
gotten away with having global side-effects in the past.  I think we
need to talk with someone who knows more about qom and qapi - Markus
seems the obvious choice.

> I'm moving forward with the libvirt implementation of pSeries
> capabilities and I would have to start implementing support for
> this new QMP command, well, pretty much... Right now :) But I'd
> rather not start at all if I'm just going to have to scrap
> everything later.

Yeah, unfortunately because its part of the core infrastructure, not
power specific, this isn't something I can make call on.

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


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

2018-01-23 Thread Peter Maydell
On 23 January 2018 at 11:13, bzt bzt  wrote:
> There's a huge misunderstanding here. I have a working qemu for about half a
> year now, and I don't need it merged. It's not my goal to submit a patch to
> qemu in any way, I just did that because I had modified an Open Source
> software and wanted to share it with the community. If you don't merge my
> patch, I don't care. Other users will.

Unfortunately we legally can't merge your patch (even if somebody
else is willing to do the work of cleaning it up) because you
haven't provided a signed-off-by line...

thanks
-- PMM



Re: [Qemu-devel] [PATCH v2] linux-user: implement renameat2

2018-01-23 Thread Laurent Vivier
Le 23/01/2018 à 11:53, Andreas Schwab a écrit :
> This is needed for new architectures like RISC-V which do not provide any
> other rename-like syscall.
> 
> Signed-off-by: Andreas Schwab 
> ---
>  linux-user/syscall.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 5e54889522..c258a0a44b 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -598,6 +598,24 @@ static int sys_utimensat(int dirfd, const char *pathname,
>  #endif
>  #endif /* TARGET_NR_utimensat */
>  
> +#ifdef TARGET_NR_renameat2
> +#if defined(__NR_renameat2)
> +#define __NR_sys_renameat2 __NR_renameat2
> +_syscall5(int, sys_renameat2, int, oldfd, const char *, old, int, newfd,
> +  const char *, new, unsigned int, flags)
> +#else
> +static int sys_renameat2(int oldfd, const char *old,
> + int newfd, const char *new, int flags)
> +{
> +if (flags == 0) {
> +return renameat(oldfd, old, newfd, new);
> +}
> +errno = ENOSYS;
> +return -1;
> +}
> +#endif
> +#endif /* TARGET_NR_renameat2 */
> +
>  #ifdef CONFIG_INOTIFY
>  #include 
>  
> @@ -8342,6 +8360,22 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  }
>  break;
>  #endif
> +#if defined(TARGET_NR_renameat2)
> +case TARGET_NR_renameat2:
> +{
> +void *p2;
> +p  = lock_user_string(arg2);
> +p2 = lock_user_string(arg4);
> +if (!p || !p2) {
> +ret = -TARGET_EFAULT;
> +} else {
> +ret = get_errno(sys_renameat2(arg1, p, arg3, p2, arg5));
> +}
> +unlock_user(p2, arg4, 0);
> +unlock_user(p, arg2, 0);
> +}
> +break;
> +#endif
>  #ifdef TARGET_NR_mkdir
>  case TARGET_NR_mkdir:
>  if (!(p = lock_user_string(arg1)))
> 

Reviewed-by: Laurent Vivier 




Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

2018-01-23 Thread Peter Maydell
On 23 January 2018 at 10:34, Christian Ehrhardt
 wrote:
> Also adding Suraj for a statement in this regard about his "[QEMU-PPC]
> [PATCH V5 0/7] target/ppc: Rework spapr_caps" series which I think is
> the PPC version of all of this right?
> Not sure who to add for Arm :-/

AIUI for Arm no QEMU changes should be required -- KVM VMs always
use the same CPU type as the host, and the kernel always exposes
the same MIDR (main ID register) value to the guest as the host has,
and the guest kernel fixes will key off the MIDR.

thanks
-- PMM



Re: [Qemu-devel] [PATCH v3 14/25] ppc: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread David Gibson
On Tue, Jan 23, 2018 at 09:08:13AM +0100, Igor Mammedov wrote:
> it will be used for providing to cpu name resolving class for
> parsing cpu model for system and user emulation code.
> 
> Along with change add target to null-machine test, so
> that when switch to CPU_RESOLVING_TYPE happens,
> test would ensure that null-mchine usecase still works.
> 
> Signed-off-by: Igor Mammedov 

Acked-by: David Gibson 

> ---
> CC: Laurent Vivier 
> CC: David Gibson 
> CC: Alexander Graf 
> CC: qemu-...@nongnu.org
> ---
>  target/ppc/cpu.h  | 1 +
>  tests/machine-none-test.c | 3 +++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index 603a38c..d5f2f3d 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -1380,6 +1380,7 @@ int ppc_dcr_write (ppc_dcr_t *dcr_env, int dcrn, 
> uint32_t val);
>  
>  #define POWERPC_CPU_TYPE_SUFFIX "-" TYPE_POWERPC_CPU
>  #define POWERPC_CPU_TYPE_NAME(model) model POWERPC_CPU_TYPE_SUFFIX
> +#define CPU_RESOLVING_TYPE TYPE_POWERPC_CPU
>  
>  #define cpu_signal_handler cpu_ppc_signal_handler
>  #define cpu_list ppc_cpu_list
> diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
> index 160aa13..052b8c0 100644
> --- a/tests/machine-none-test.c
> +++ b/tests/machine-none-test.c
> @@ -41,6 +41,9 @@ static struct arch2cpu cpus_map[] = {
>  { "moxie", "MoxieLite" },
>  { "nios2", "FIXME" },
>  { "or1k", "or1200" },
> +{ "ppc", "604" },
> +{ "ppc64", "power8e_v2.1" },
> +{ "ppcemb", "440epb" },
>  };
>  
>  static const char *get_cpu_model_by_arch(const char *arch)

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


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH v3 24/25] cpu: get rid of unused cpu_init() defines

2018-01-23 Thread David Gibson
On Tue, Jan 23, 2018 at 09:08:23AM +0100, Igor Mammedov wrote:
> cpu_init(cpu_model) were replaced by cpu_create(cpu_type) so
> no users are left, remove it.
> 
> Signed-off-by: Igor Mammedov 

ppc parts

Acked-by: David Gibson 

> ---
> CC: Richard Henderson  (maintainer:Alpha)
> CC: Peter Maydell 
> CC: "Edgar E. Iglesias" 
> CC: Eduardo Habkost 
> CC: Michael Walle 
> CC: Laurent Vivier 
> CC: Aurelien Jarno 
> CC: Yongbok Kim 
> CC: Anthony Green 
> CC: Chris Wulff 
> CC: Marek Vasut 
> CC: Stafford Horne 
> CC: David Gibson 
> CC: Alexander Graf 
> CC: Mark Cave-Ayland 
> CC: Artyom Tarasenko 
> CC: Bastian Koppelmann 
> CC: Guan Xuetao 
> CC: Max Filippov 
> CC: qemu-...@nongnu.org
> CC: qemu-...@nongnu.org
> CC: qemu-s3...@nongnu.org
> ---
>  target/alpha/cpu.h  | 2 --
>  target/arm/cpu.h| 2 --
>  target/cris/cpu.h   | 2 --
>  target/hppa/cpu.h   | 1 -
>  target/i386/cpu.h   | 2 --
>  target/lm32/cpu.h   | 2 --
>  target/m68k/cpu.h   | 2 --
>  target/microblaze/cpu.h | 1 -
>  target/mips/cpu.h   | 2 --
>  target/moxie/cpu.h  | 2 --
>  target/nios2/cpu.h  | 1 -
>  target/openrisc/cpu.h   | 2 --
>  target/ppc/cpu.h| 2 --
>  target/s390x/cpu.h  | 2 --
>  target/sh4/cpu.h| 2 --
>  target/sparc/cpu.h  | 4 
>  target/tilegx/cpu.h | 1 -
>  target/tricore/cpu.h| 2 --
>  target/unicore32/cpu.h  | 2 --
>  target/xtensa/cpu.h | 2 --
>  20 files changed, 38 deletions(-)
> 
> diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
> index 21ed5d6..b3bec21 100644
> --- a/target/alpha/cpu.h
> +++ b/target/alpha/cpu.h
> @@ -468,8 +468,6 @@ enum {
>  
>  void alpha_translate_init(void);
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_ALPHA_CPU, cpu_model)
> -
>  #define ALPHA_CPU_TYPE_SUFFIX "-" TYPE_ALPHA_CPU
>  #define ALPHA_CPU_TYPE_NAME(model) model ALPHA_CPU_TYPE_SUFFIX
>  #define CPU_RESOLVING_TYPE TYPE_ALPHA_CPU
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index f9fb141..b37d266 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -2167,8 +2167,6 @@ static inline bool arm_excp_unmasked(CPUState *cs, 
> unsigned int excp_idx,
>  return unmasked || pstate_unmasked;
>  }
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_ARM_CPU, cpu_model)
> -
>  #define ARM_CPU_TYPE_SUFFIX "-" TYPE_ARM_CPU
>  #define ARM_CPU_TYPE_NAME(name) (name ARM_CPU_TYPE_SUFFIX)
>  #define CPU_RESOLVING_TYPE TYPE_ARM_CPU
> diff --git a/target/cris/cpu.h b/target/cris/cpu.h
> index 1a27653..db80cb1 100644
> --- a/target/cris/cpu.h
> +++ b/target/cris/cpu.h
> @@ -267,8 +267,6 @@ enum {
>  #define TARGET_PHYS_ADDR_SPACE_BITS 32
>  #define TARGET_VIRT_ADDR_SPACE_BITS 32
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_CRIS_CPU, cpu_model)
> -
>  #define CRIS_CPU_TYPE_SUFFIX "-" TYPE_CRIS_CPU
>  #define CRIS_CPU_TYPE_NAME(name) (name CRIS_CPU_TYPE_SUFFIX)
>  #define CPU_RESOLVING_TYPE TYPE_CRIS_CPU
> diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
> index b92ae3f..628d7de 100644
> --- a/target/hppa/cpu.h
> +++ b/target/hppa/cpu.h
> @@ -112,7 +112,6 @@ static inline int cpu_mmu_index(CPUHPPAState *env, bool 
> ifetch)
>  
>  void hppa_translate_init(void);
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_HPPA_CPU, cpu_model)
>  #define CPU_RESOLVING_TYPE TYPE_HPPA_CPU
>  
>  void hppa_cpu_list(FILE *f, fprintf_function cpu_fprintf);
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 82c7381..1ed60b0 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1564,8 +1564,6 @@ uint64_t cpu_get_tsc(CPUX86State *env);
>  
>  #define PHYS_ADDR_MASK MAKE_64BIT_MASK(0, TCG_PHYS_ADDR_BITS)
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_X86_CPU, cpu_model)
> -
>  #define X86_CPU_TYPE_SUFFIX "-" TYPE_X86_CPU
>  #define X86_CPU_TYPE_NAME(name) (name X86_CPU_TYPE_SUFFIX)
>  #define CPU_RESOLVING_TYPE TYPE_X86_CPU
> diff --git a/target/lm32/cpu.h b/target/lm32/cpu.h
> index 0656052..53939e5 100644
> --- a/target/lm32/cpu.h
> +++ b/target/lm32/cpu.h
> @@ -255,8 +255,6 @@ void lm32_watchpoint_insert(CPULM32State *env, int index, 
> target_ulong address,
>  void lm32_watchpoint_remove(CPULM32State *env, int index);
>  bool lm32_cpu_do_semihosting(CPUState *cs);
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_LM32_CPU, cpu_model)
> -
>  #define LM32_CPU_TYPE_SUFFIX "-" TYPE_LM32_CPU
>  #define LM32_CPU_TYPE_NAME(model) model LM32_CPU_TYPE_SUFFIX
>  #define CPU_RESOLVING_TYPE TYPE_LM32_CPU
> diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
> index 8a4299a..7d64804 100644
> --- a/target/m68k/cpu.h
> +++ b/target/m68k/cpu.h
> @@ -401,8 +401,6 @@ void register_m68k_insns (CPUM68KState *env);
>  #define TARGET_PHYS_ADDR_SPACE_BITS 32
>  #define TARGET_VIRT_ADDR_SPACE_BITS 32
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_M68K_CPU, cpu_model)
> -
>  #define M68K_CPU_TYPE_SUFFIX "-" TYPE_M68K_CPU
>  #define M68K_CPU_TYPE_NAME(model) model M68K_CPU_TYPE_SUFFIX
>  #define CPU_RESOLVING_TYPE

Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

2018-01-23 Thread bzt bzt
On Mon, Jan 22, 2018 at 12:41 PM, BALATON Zoltan  wrote:

> Hello,
>
> On Thu, 18 Jan 2018, bzt bzt wrote:
>
>> Since you still haven't merged Alistair's patch, I decided to include it
>> in
>> my own.
>>
>
> Which patch exactly are you referring to?


The one I linked earlier, which also added CPU model to the mc class.


> Please be patient and don't get upset.


I'm not in-patent and I'm not upset. I can emulate raspi3, and I'm very
happy with it! Other users may be upset about you (plural) because they
can't use binary distributions and have to compile qemu from my source if
they want to have raspi3 support.


> Merging a patch can take some time, especially if code freeze and holiday
> season are in the middle and some backlog is accumulated. I suggest to
> follow instructions described here:
>
> https://wiki.qemu.org/Contribute/SubmitAPatch
>
> and send this version as a new message with proper format and commit
> message so it can be easily found and tested by relevant people and don't
> give up if they are busy and can't reply immediately. Just politely remind
> them after a week or two as suggested on the above wiki page.
>

There's a huge misunderstanding here. I have a working qemu for about half
a year now, and I don't need it merged. It's not my goal to submit a patch
to qemu in any way, I just did that because I had modified an Open Source
software and wanted to share it with the community. If you don't merge my
patch, I don't care. Other users will.


>
> Rationale for the above: Replying to an older thread may not show up at
> the end if someone uses threaded view but gets burried in some old thread
> so new patches should be new top level threads, only replies to the same
> patch or series should be sent as replies. Also your patch has been mangled
> by the email client and some lines are broken. This is a problem because it
> cannot be tested by using git am so it's more difficult to check. Please
> make sure you send it unflowed so the patch is not changed by the client
> (or use git send-email).
>

Again, if you want to provide raspi3 support (as more and more users
require it), use my patch or my git repo. I don't have to or want to do
anything more about it.


> All in all, I think your work is interesting and the lack of reply only
> means that people who could review and merge it were too busy not lack of
> interest so keep up improving the patch and don't give up.
>

I won't improve my patch any further, 'cos it's working perfectly for me.
Don't try to fix what's not broken!

Regards,
bzt


> Regards,
> BALATON Zoltan
>
>
> I've shrinked the number of modified files to two, that's the bare minimum
>> to support "-M raspi3" switch. Bcm2836.c modified minimally, the rest is
>> in
>> raspi.c. I've renamed raspi2_init() to raspi_init() 'cos now it
>> initializes
>> raspi3 as well, no additional function.
>>
>> diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
>> index 8c43291112..5119e00051 100644
>> --- a/hw/arm/bcm2836.c
>> +++ b/hw/arm/bcm2836.c
>> @@ -15,6 +15,7 @@
>> #include "hw/arm/bcm2836.h"
>> #include "hw/arm/raspi_platform.h"
>> #include "hw/sysbus.h"
>> +#include "hw/boards.h"
>> #include "exec/address-spaces.h"
>>
>> /* Peripheral base address seen by the CPU */
>> @@ -30,7 +31,7 @@ static void bcm2836_init(Object *obj)
>>
>> for (n = 0; n < BCM2836_NCPUS; n++) {
>> object_initialize(&s->cpus[n], sizeof(s->cpus[n]),
>> -  "cortex-a15-" TYPE_ARM_CPU);
>> +  current_machine->cpu_type);
>> object_property_add_child(obj, "cpu[*]", OBJECT(&s->cpus[n]),
>>   &error_abort);
>> }
>> diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
>> index cd5fa8c3dc..24a9243440 100644
>> --- a/hw/arm/raspi.c
>> +++ b/hw/arm/raspi.c
>> @@ -5,6 +5,8 @@
>>  * Rasperry Pi 2 emulation Copyright (c) 2015, Microsoft
>>  * Written by Andrew Baumann
>>  *
>> + * Raspberry Pi 3 emulation Copyright (c) 2018 by bzt
>> + *
>>  * This code is licensed under the GNU GPLv2 and later.
>>  */
>>
>> @@ -22,10 +24,11 @@
>> #define SMPBOOT_ADDR0x300 /* this should leave enough space for ATAGS
>> */
>> #define MVBAR_ADDR  0x400 /* secure vectors */
>> #define BOARDSETUP_ADDR (MVBAR_ADDR + 0x20) /* board setup code */
>> -#define FIRMWARE_ADDR   0x8000 /* Pi loads kernel.img here by default */
>> +#define FIRMWARE_ADDR_20x8000 /* Pi 2 loads kernel.img here by
>> default
>> */
>> +#define FIRMWARE_ADDR_3   0x8 /* Pi 3 loads kernel8.img here by
>> default */
>>
>> /* Table of Linux board IDs for different Pi versions */
>> -static const int raspi_boardid[] = {[1] = 0xc42, [2] = 0xc43};
>> +static const int raspi_boardid[] = {[1] = 0xc42, [2] = 0xc43, [3] =
>> 0xc44};
>>
>> typedef struct RasPiState {
>> BCM2836State soc;
>> @@ -83,8 +86,8 @@ static void setup_boot(MachineState *machine, int
>> version, size_t ram_size)
>> binfo.secure_board_setup = true;
>> binfo.secure_boot = true;
>>
>> -/*

Re: [Qemu-devel] [RFC 0/2] virtio-vhost-user: add virtio-vhost-user device

2018-01-23 Thread Stefan Hajnoczi
On Mon, Jan 22, 2018 at 07:09:06PM +0800, Wei Wang wrote:
> On 01/19/2018 09:06 PM, Stefan Hajnoczi wrote:
> Thanks for the quick implementation. Not sure if the following issues could
> be solved with this approach:
>  - After we boot the slave VM, if we don't run the virtio-vhost-user driver
> (i.e. testpmd), then the master VM couldn't boot, because the booting of the
> virtio-net device relies on a negotiation with the virtio-vhost-user driver.

This is a limitation of QEMU's vhost-user master implementation which
also affects AF_UNIX.  It cannot be solved by this patch series since
this is the slave side.

Here is what I suggest.  Introduce a new VIRTIO feature bit:

  #define VIRTIO_F_DEVICE_READY 34

When the device supports this bit we extend the device initialization
procedure.  If the device is not yet ready, the FEATURES_OK status bit
is not accepted by the device.  Device initialization fails temporarily
but the device may raise the configuration change interrupt to indicate
that device initialization should be retried.

Using a feature bit guarantees that existing device and driver behavior
remains unchanged.

On the QEMU side the changes are:

1. Virtio hardware registers and configuration space are available even
   when vhost-user is disconnected.  This shouldn't be difficult to
   implement because QEMU always has a virtio device model for each
   vhost-user device.  We just need to put dummy values in the
   registers/configuration space until vhost-user has connected.

2. When vhost-user connects, raise the configuration change interrupt
   and allow vhost-user to process.

On the guest side the changes are:

1. virtio_pci.ko must set VIRTIO_F_DEVICE_READY and handle !FEATURES_OK
   by waiting for the configuration change interrupt and retrying.

This doesn't fully solve the problem because it assumes that a connected
slave always responds to VIRTIO hardware register accesses (e.g. get/set
features).  If the slave crashes but leaves the virtio-vhost-user PCI
adapter connected then vhost-user requests from the master go
unanswered and cause hangs...

>  - Suppose in the future there is also a kernel virtio-vhost-user driver as
> other PCI devices, can we unbind the kernel driver first, and then bind the
> device to the dpdk driver? A normal PCI device should be able to smoothly
> switch between the kernel driver and dpdk driver.

It depends what you mean by "smoothly switch".

If you mean whether it's possible to go from a kernel driver to
vfio-pci, then the answer is yes.

But if the kernel driver has an established vhost-user connection then
it will be closed.  This is the same as reconnecting with AF_UNIX
vhost-user.

Stefan


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH] linux-user: implement renameat2

2018-01-23 Thread Laurent Vivier
Le 23/01/2018 à 11:26, Andreas Schwab a écrit :
> On Jan 23 2018, Laurent Vivier  wrote:
> 
>> And, please, test it (build/run).
> 
> This was tested by bootstrapping openSUSE Factory for RISC-V.

I have no doubt on this part, but you should test the "#else" part too,
by, for instance, undefining "__NR_renameat2" locally/temporarily.

Thanks,
Laurent



[Qemu-devel] [PATCH v2] linux-user: implement renameat2

2018-01-23 Thread Andreas Schwab
This is needed for new architectures like RISC-V which do not provide any
other rename-like syscall.

Signed-off-by: Andreas Schwab 
---
 linux-user/syscall.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 5e54889522..c258a0a44b 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -598,6 +598,24 @@ static int sys_utimensat(int dirfd, const char *pathname,
 #endif
 #endif /* TARGET_NR_utimensat */
 
+#ifdef TARGET_NR_renameat2
+#if defined(__NR_renameat2)
+#define __NR_sys_renameat2 __NR_renameat2
+_syscall5(int, sys_renameat2, int, oldfd, const char *, old, int, newfd,
+  const char *, new, unsigned int, flags)
+#else
+static int sys_renameat2(int oldfd, const char *old,
+ int newfd, const char *new, int flags)
+{
+if (flags == 0) {
+return renameat(oldfd, old, newfd, new);
+}
+errno = ENOSYS;
+return -1;
+}
+#endif
+#endif /* TARGET_NR_renameat2 */
+
 #ifdef CONFIG_INOTIFY
 #include 
 
@@ -8342,6 +8360,22 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 }
 break;
 #endif
+#if defined(TARGET_NR_renameat2)
+case TARGET_NR_renameat2:
+{
+void *p2;
+p  = lock_user_string(arg2);
+p2 = lock_user_string(arg4);
+if (!p || !p2) {
+ret = -TARGET_EFAULT;
+} else {
+ret = get_errno(sys_renameat2(arg1, p, arg3, p2, arg5));
+}
+unlock_user(p2, arg4, 0);
+unlock_user(p, arg2, 0);
+}
+break;
+#endif
 #ifdef TARGET_NR_mkdir
 case TARGET_NR_mkdir:
 if (!(p = lock_user_string(arg1)))
-- 
2.16.1


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



Re: [Qemu-devel] [qemu-s390x] [PULL 0/8] x86 queue, 2018-01-17

2018-01-23 Thread Cornelia Huck
On Tue, 23 Jan 2018 11:34:18 +0100
Christian Ehrhardt  wrote:

> On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger
>  wrote:
> >
> >
> > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:  
> >> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell  
> >> wrote:  
> >>> On 18 January 2018 at 02:01, Eduardo Habkost  wrote: 
> >>>  
>  The following changes since commit 
>  8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> 
>    Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into 
>  staging (2018-01-16 17:36:39 +)
> 
>  are available in the Git repository at:
> 
>    git://github.com/ehabkost/qemu.git tags/x86-pull-request
> 
>  for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
> 
>    i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> 
>  
>  x86 queue, 2018-01-17
> 
>  Highlight: new CPU models that expose CPU features that guests
>  can use to mitigate CVE-2017-5715 (Spectre variant #2).
>   
> >>>
> >>> Applied, thanks.
> >>>
> >>> -- PMM
> >>>  
> >>
> >> Hi,
> >> I was kind of clinging to [1] so far and had the expectation that all
> >> those would be wrapped up in 2.11.1 once ready.
> >> I see that the s390x changes are targeted to qemu-stable (well to
> >> admit I suggested so referring the article above).
> >> So I'd expected to see this series to show up on qemu-stable as well
> >> but haven't seen it so far.
> >>
> >> Therefore I wanted to ask if there was a change of plans in that
> >> regard or if it needs just a few days more to see (part of) this
> >> series on qemu-stable and on its way into 2.11.1?
> >>
> >> [1]: https://www.qemu.org/2018/01/04/spectre/  
> >
> > Adding Michael,
> >
> > Yes, I think it makes sense to have the guest enablement for the spectre
> > mitigations available in 2.11.1 for all architectures that provide it.
> > (this queue for x86, Connies pending S390 patches, whatever Power
> > and arm will do).  
> 
> Also adding Suraj for a statement in this regard about his "[QEMU-PPC]
> [PATCH V5 0/7] target/ppc: Rework spapr_caps" series which I think is
> the PPC version of all of this right?
> Not sure who to add for Arm :-/
> 
> @Cornelia - the consumers of these stable changes in particular IMHO
> are Distributions for security updates.
> Seeing at least one backport into 2.11.1 would be very helpful to
> avoid issues that would not apply to a forward thinking 2.12 commit.
> Such a (even short distance) backport being done by the Author would
> have the lowest risk of such issues creeping in.
> I'm not so sure on 2.(<11).x  - but one backport at least into the
> latest release would be very nice to fulfill the [1] announcement
> referenced above and provide a first release of these important
> changes available earlier than full 2.12.

I agree that a backport unto 2.11.x is useful.

But I still think we should clarify the purpose of our stable tree --
not necessarily in this thread, though.



Re: [Qemu-devel] [RFC 0/2] virtio-vhost-user: add virtio-vhost-user device

2018-01-23 Thread Wei Wang

On 01/22/2018 08:17 PM, Stefan Hajnoczi wrote:

On Mon, Jan 22, 2018 at 11:33:46AM +0800, Jason Wang wrote:

On 2018年01月19日 21:06, Stefan Hajnoczi wrote:

Probably not for the following cases:

1) kick/call

I disagree here because kick/call is actually very efficient!

VM1's irqfd is the ioeventfd for VM2.  When VM2 writes to the ioeventfd
there is a single lightweight vmexit which injects an interrupt into
VM1.  QEMU is not involved and the host kernel scheduler is not involved
so this is a low-latency operation.

I haven't tested this yet but the ioeventfd code looks like this will
work.



This have been tested in vhost-pci v2 patches which worked with with a 
kernel driver. It worked pretty well.



Btw, it's better to have some early numbers, e.g what testpmd reports during
forwarding.

I need to rely on others to do this (and many other things!) because
virtio-vhost-user isn't the focus of my work.

These patches were written to demonstrate my suggestions for vhost-pci.
They were written at work but also on weekends, early mornings, and late
nights to avoid delaying Wei and Zhiyong's vhost-pci work too much.

If this approach has merit then I hope others will take over and I'll
play a smaller role addressing some of the todo items and cleanups.


Thanks again for the great effort, your implementation looks nice.

If we finally decide to go with the virtio-vhost-user approach, I think 
zhiyong and I can help take over the work to continue, too.


I'm still thinking about solutions to the two issues that I shared 
yesterday - it should be like a normal PCI device, and if we unbind its 
driver, and bind back, it should also work.



Best,
Wei






Re: [Qemu-devel] [PATCH v2 3/8] ide: account UNMAP (TRIM) operations

2018-01-23 Thread Anton Nefedov



On 22/1/2018 11:48 PM, Eric Blake wrote:

On 01/19/2018 06:50 AM, Anton Nefedov wrote:

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




@@ -460,10 +468,15 @@ static void ide_issue_trim_cb(void *opaque, int ret)
  }
  
  if (!ide_sect_range_ok(s, sector, count)) {

+block_acct_invalid(blk_get_stats(s->blk),
+   BLOCK_ACCT_UNMAP);
  iocb->is_invalid = true;
  goto done;
  }
  
+block_acct_start(blk_get_stats(s->blk), &s->acct,

+ count << BDRV_SECTOR_BITS, BLOCK_ACCT_UNMAP);


We're still mixing bytes- and block-based reporting; how easy or hard
would it be to flip block_acct_start() and friends to be byte-based?


Quite easy, they already are :)



Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

2018-01-23 Thread Christian Ehrhardt
On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger
 wrote:
>
>
> On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
>> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell  
>> wrote:
>>> On 18 January 2018 at 02:01, Eduardo Habkost  wrote:
 The following changes since commit 
 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:

   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into 
 staging (2018-01-16 17:36:39 +)

 are available in the Git repository at:

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

 for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:

   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)

 
 x86 queue, 2018-01-17

 Highlight: new CPU models that expose CPU features that guests
 can use to mitigate CVE-2017-5715 (Spectre variant #2).

>>>
>>> Applied, thanks.
>>>
>>> -- PMM
>>>
>>
>> Hi,
>> I was kind of clinging to [1] so far and had the expectation that all
>> those would be wrapped up in 2.11.1 once ready.
>> I see that the s390x changes are targeted to qemu-stable (well to
>> admit I suggested so referring the article above).
>> So I'd expected to see this series to show up on qemu-stable as well
>> but haven't seen it so far.
>>
>> Therefore I wanted to ask if there was a change of plans in that
>> regard or if it needs just a few days more to see (part of) this
>> series on qemu-stable and on its way into 2.11.1?
>>
>> [1]: https://www.qemu.org/2018/01/04/spectre/
>
> Adding Michael,
>
> Yes, I think it makes sense to have the guest enablement for the spectre
> mitigations available in 2.11.1 for all architectures that provide it.
> (this queue for x86, Connies pending S390 patches, whatever Power
> and arm will do).

Also adding Suraj for a statement in this regard about his "[QEMU-PPC]
[PATCH V5 0/7] target/ppc: Rework spapr_caps" series which I think is
the PPC version of all of this right?
Not sure who to add for Arm :-/

@Cornelia - the consumers of these stable changes in particular IMHO
are Distributions for security updates.
Seeing at least one backport into 2.11.1 would be very helpful to
avoid issues that would not apply to a forward thinking 2.12 commit.
Such a (even short distance) backport being done by the Author would
have the lowest risk of such issues creeping in.
I'm not so sure on 2.(<11).x  - but one backport at least into the
latest release would be very nice to fulfill the [1] announcement
referenced above and provide a first release of these important
changes available earlier than full 2.12.

cu
Christian



Re: [Qemu-devel] [PATCH v2 2/8] qapi: add unmap to BlockDeviceStats

2018-01-23 Thread Anton Nefedov



On 22/1/2018 11:47 PM, Eric Blake wrote:

On 01/19/2018 06:50 AM, Anton Nefedov wrote:

Signed-off-by: Anton Nefedov 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Alberto Garcia 
---
  qapi/block-core.json   | 29 +++--
  include/block/accounting.h |  1 +
  block/qapi.c   |  6 ++
  3 files changed, 30 insertions(+), 6 deletions(-)




@@ -688,6 +693,9 @@
  #
  # @rd_total_time_ns: Total_time_spend on reads in nano-seconds (since 0.15.0).


While we are here, we could change s/Total_time_spend/Total time spent/


  #
+# @unmap_total_time_ns: Total time spent on unmap operations in nano-seconds
+#   (Since 2.12)


Also, s/nano-seconds/nanoseconds/ (for both lines, if we are touching both).

The QAPI maintainer can touch that up (that may be me, depending on
Markus' schedule in the next few weeks); but I'm not seeing any UI
problems with the addition, so

Reviewed-by: Eric Blake 



Thanks, fixed



Re: [Qemu-devel] [PATCH] linux-user: implement renameat2

2018-01-23 Thread Andreas Schwab
On Jan 23 2018, Laurent Vivier  wrote:

> And, please, test it (build/run).

This was tested by bootstrapping openSUSE Factory for RISC-V.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



Re: [Qemu-devel] [PATCH] linux-user: implement renameat2

2018-01-23 Thread Andreas Schwab
On Jan 23 2018, Laurent Vivier  wrote:

> Please fix style problem reported by patchew
> (or ./scripts/checkpatch.pl)

This was mostly copy-pasted from surrounding code. :-)

>> @@ -8342,6 +8359,22 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
>> arg1,
>>  }
>>  break;
>>  #endif
>> +#if defined(TARGET_NR_renameat2)
>> +case TARGET_NR_renameat2:
>> +{
>> +void *p2;
>> +p  = lock_user_string(arg2);
>> +p2 = lock_user_string(arg4);
>> +if (!p || !p2)
>> +ret = -TARGET_EFAULT;
>> +else
>> +ret = get_errno(sys_renameat2(arg1, p, arg3, p2,
>> +  target_to_host_bitmask(arg5, 
>> fcntl_flags_tbl)));
>
> You can't use fcntl_flags_tbl

Of course!  I was confused by another patch I was working on which does
need such a conversion. :-/

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



Re: [Qemu-devel] [qemu-s390x] [PULL 0/8] x86 queue, 2018-01-17

2018-01-23 Thread Cornelia Huck
On Tue, 23 Jan 2018 10:59:39 +0100
Christian Borntraeger  wrote:

> On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
> > On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell  
> > wrote:  
> >> On 18 January 2018 at 02:01, Eduardo Habkost  wrote:  
> >>> The following changes since commit 
> >>> 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> >>>
> >>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into 
> >>> staging (2018-01-16 17:36:39 +)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
> >>>
> >>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
> >>>
> >>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> >>>
> >>> 
> >>> x86 queue, 2018-01-17
> >>>
> >>> Highlight: new CPU models that expose CPU features that guests
> >>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
> >>>  
> >>
> >> Applied, thanks.
> >>
> >> -- PMM
> >>  
> > 
> > Hi,
> > I was kind of clinging to [1] so far and had the expectation that all
> > those would be wrapped up in 2.11.1 once ready.
> > I see that the s390x changes are targeted to qemu-stable (well to
> > admit I suggested so referring the article above).
> > So I'd expected to see this series to show up on qemu-stable as well
> > but haven't seen it so far.
> > 
> > Therefore I wanted to ask if there was a change of plans in that
> > regard or if it needs just a few days more to see (part of) this
> > series on qemu-stable and on its way into 2.11.1?
> > 
> > [1]: https://www.qemu.org/2018/01/04/spectre/  
> 
> Adding Michael,
> 
> Yes, I think it makes sense to have the guest enablement for the spectre 
> mitigations available in 2.11.1 for all architectures that provide it. 
> (this queue for x86, Connies pending S390 patches, whatever Power
> and arm will do).

Also note that we will need a headers update for 2.11.1.

> 
> Not sure about a 2.10.3?

I'm not sure how far back we want to do stable changes (the further
back, the more likely it is that the patches need some massaging).
Also, I'm still not quite sure what the intended consumers are for our
stable trees.



Re: [Qemu-devel] [PULL 00/43] Add hppa-softmmu

2018-01-23 Thread Peter Maydell
On 22 January 2018 at 03:41, Richard Henderson
 wrote:
> This has some improvements to the patch set posted on Dec 28.
>
>   * Change cpu init as requested by Igor Mammedov.
>   * Add SMP support
>   * Add firmware image
>   * Implement qemu-specific pause and system reset insns.
>
>
> r~
>
>
> The following changes since commit b384cd95eb9c6f73ad84ed1bb0717a26e29cc78f:
>
>   Merge remote-tracking branch 
> 'remotes/ehabkost/tags/machine-next-pull-request' into staging (2018-01-19 
> 16:35:25 +)
>
> are available in the Git repository at:
>
>   git://github.com/rth7680/qemu.git tags/pull-hppa-20180121
>
> for you to fetch changes up to 350e2a714ac8db559b255f9e8fe91c574f45df53:
>
>   hw/hppa: Add MAINTAINERS entry (2018-01-21 14:05:03 -0800)
>
> 
> Add hppa-softmmu

Hi. Patchew is complaining that this doesn't build on some hosts:


/var/tmp/patchew-tester-tmp-z8zo58jf/src/target/sh4/op_helper.c: In
function ‘superh_cpu_do_unaligned_access’:
/var/tmp/patchew-tester-tmp-z8zo58jf/src/target/sh4/op_helper.c:31:5:
error: enumeration value ‘MMU_DEBUG_LOAD’ not handled in switch
[-Werror=switch]
 switch (access_type) {
 ^~

so I'm going to drop it from my to-process queue.

Also, the patchew coding style check seems to be showing a lot
of whitespace and similar nits which I don't think there's any
reason to have in new code. Could you also fix those, please?

thanks
-- PMM



Re: [Qemu-devel] [RFC 0/2] virtio-vhost-user: add virtio-vhost-user device

2018-01-23 Thread Stefan Hajnoczi
On Mon, Jan 22, 2018 at 10:04:18PM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 22, 2018 at 12:17:51PM +, Stefan Hajnoczi wrote:
> > On Mon, Jan 22, 2018 at 11:33:46AM +0800, Jason Wang wrote:
> > > On 2018年01月19日 21:06, Stefan Hajnoczi wrote:
> > > > These patches implement the virtio-vhost-user device design that I have
> > > > described here:
> > > > https://stefanha.github.io/virtio/vhost-user-slave.html#x1-2830007
> > > 
> > > Thanks for the patches, looks rather interesting and similar to split 
> > > device
> > > model used by Xen.
> > > 
> > > > 
> > > > The goal is to let the guest act as the vhost device backend for other 
> > > > guests.
> > > > This allows virtual networking and storage appliances to run inside 
> > > > guests.
> > > 
> > > So the question still, what kind of protocol do you want to run on top? If
> > > it was ethernet based, virtio-net work pretty well and it can even do
> > > migration.
> > > 
> > > > This device is particularly interesting for poll mode drivers where 
> > > > exitless
> > > > VM-to-VM communication is possible, completely bypassing the hypervisor 
> > > > in the
> > > > data path.
> > > 
> > > It's better to clarify the reason of hypervisor bypassing. (performance,
> > > security or scalability).
> > 
> > Performance - yes, definitely.  Exitless VM-to-VM is the fastest
> > possible way to communicate between VMs.  Today it can only be done
> > using ivshmem.  This patch series allows virtio devices to take
> > advantage of it and will encourage people to use virtio instead of
> > non-standard ivshmem devices.
> > 
> > Security - I don't think this feature is a security improvement.  It
> > reduces isolation because VM1 has full shared memory access to VM2.  In
> > fact, this is a reason for users to consider carefully whether they
> > even want to use this feature.
> 
> True without an IOMMU, however using a vIOMMU within VM2
> can protect the VM2, can't it?
[...]
> > Yes, this is the big weakness of vhost-user in general.  The IOMMU
> > feature doesn't offer good isolation
> 
> I think that's an implementation issue, not a protocol issue.

The IOMMU feature in the vhost-user protocol adds address translation
and permissions but the underlying memory region file descriptors still
expose all of guest RAM.

An implementation that offers true isolation has to enforce the IOMMU
state on the shared memory (e.g. read & write access).

> > and even when it does, performance
> > will be an issue.
> 
> If the IOMMU mappings are dynamic - but they are mostly
> static with e.g. dpdk, right?

Excellent idea!  My understanding is that DPDK's memory area for mbufs
is static.

The question is whether this area contains only packet payload buffers?
Then it would be feasible to map only this memory (plus vrings) and
achieve isolation.

If other data is intermingled with the packet payload buffers then it's
difficult to guarantee security since an evil VM can modify the
non-payload data to trigger race conditions, out-of-bounds memory
accesses, and other bugs.

Anyway, what you've suggested sounds like the most realistic option for
achieving isolation without losing performance.

> > > >   * Implement the VRING_KICK eventfd - currently vhost-user slaves must 
> > > > be poll
> > > > mode drivers.
> > > >   * Optimize VRING_CALL doorbell with ioeventfd to avoid QEMU exit.
> > > 
> > > The performance implication needs to be measured. It looks to me both kick
> > > and call will introduce more latency form the point of guest.
> > 
> > I described the irqfd + ioeventfd approach above.  It should be faster
> > than virtio-net + bridge today.
> > 
> > > >   * vhost-user log feature
> > > >   * UUID config field for stable device identification regardless of PCI
> > > > bus addresses.
> > > >   * vhost-user IOMMU and SLAVE_REQ_FD feature
> > > 
> > > So an assumption is the VM that implements vhost backends should be at 
> > > least
> > > as secure as vhost-user backend process on host. Could we have this
> > > conclusion?
> > 
> > Yes.
> > 
> > Sadly the vhost-user IOMMU protocol feature does not provide isolation.
> > At the moment IOMMU is basically a layer of indirection (mapping) but
> > the vhost-user backend process still has full access to guest RAM :(.
> 
> An important feature would be to do the isolation in the qemu.
> So trust the qemu running VM2 but not VM2 itself.

I think what you suggested above about DPDK's static mappings is even
better.  It does not require trusting VM2's QEMU.  It's also simpler
than implementing isolation in QEMU.


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PULL 00/27] Migration pull

2018-01-23 Thread Peter Maydell
On 22 January 2018 at 13:38, Peter Maydell  wrote:
> On 22 January 2018 at 12:38, Dr. David Alan Gilbert  
> wrote:
>> It's probably better to remove the whole set of 6, then we can come
>> back to it later rather than leaving something half-implemented in
>> there.
>
> OK. I'm currently running a commit with
>  git revert --no-commit 31bf06a9d6844d^..ca6011c232912
> through my build tests, though I'll hold off on actually pushing it
> for a bit to give people time to comment.

I've now pushed this revert to master.

thanks
-- PMM



Re: [Qemu-devel] [RFC PATCH qemu] qmp: Add qom-list-properties to list QOM object properties

2018-01-23 Thread Andrea Bolognani
On Fri, 2018-01-19 at 15:34 +0100, Andrea Bolognani wrote:
> > > This won't solve the libvirt problem we were discussing, because it
> > > needs an existing instance of the object.  libvirt wants to know the
> > > machine properties *without* instantiating an instance.
> > 
> > My patch works with types, it creates an instance for a short time itself,
> > this is why it does not do a thing for "pseries" as it is not a type and
> > prints properties for the "pseries-2.12-machine" type.
> 
> Yeah, I took this for a spin and can confirm that it's pretty much
> exactly what I was thinking about. The fact that the QMP command
> instantiates objects behind the scenes is not an issue, at least
> from libvirt's point of view: device-list-properties does the same
> thing and we already use it quite happily; what matters is that we
> can call this, along with all the other capabilities-collecting
> QMP commands, in one go and on a single QEMU instance.

David, I know you're busy with linux.conf.au, but it would be
really helpful if you could carve out five minutes to look over
Alexey's proposal again, with my reply above in mind, and let us
know whether it looks a reasonable design. Doesn't have to be a
review, just a quick feedback on the high-level idea.

I'm moving forward with the libvirt implementation of pSeries
capabilities and I would have to start implementing support for
this new QMP command, well, pretty much... Right now :) But I'd
rather not start at all if I'm just going to have to scrap
everything later.

Thanks.

-- 
Andrea Bolognani / Red Hat / Virtualization



Re: [Qemu-devel] [RFC 0/2] virtio-vhost-user: add virtio-vhost-user device

2018-01-23 Thread Jason Wang



On 2018年01月23日 04:04, Michael S. Tsirkin wrote:

On Mon, Jan 22, 2018 at 12:17:51PM +, Stefan Hajnoczi wrote:

On Mon, Jan 22, 2018 at 11:33:46AM +0800, Jason Wang wrote:

On 2018年01月19日 21:06, Stefan Hajnoczi wrote:

These patches implement the virtio-vhost-user device design that I have
described here:
https://stefanha.github.io/virtio/vhost-user-slave.html#x1-2830007

Thanks for the patches, looks rather interesting and similar to split device
model used by Xen.


The goal is to let the guest act as the vhost device backend for other guests.
This allows virtual networking and storage appliances to run inside guests.

So the question still, what kind of protocol do you want to run on top? If
it was ethernet based, virtio-net work pretty well and it can even do
migration.


This device is particularly interesting for poll mode drivers where exitless
VM-to-VM communication is possible, completely bypassing the hypervisor in the
data path.

It's better to clarify the reason of hypervisor bypassing. (performance,
security or scalability).

Performance - yes, definitely.  Exitless VM-to-VM is the fastest
possible way to communicate between VMs.  Today it can only be done
using ivshmem.  This patch series allows virtio devices to take
advantage of it and will encourage people to use virtio instead of
non-standard ivshmem devices.

Security - I don't think this feature is a security improvement.  It
reduces isolation because VM1 has full shared memory access to VM2.  In
fact, this is a reason for users to consider carefully whether they
even want to use this feature.

True without an IOMMU, however using a vIOMMU within VM2
can protect the VM2, can't it?


It's not clear to me how to do this. E.g need a way to report failure to 
VM2 or #PF?





Scalability - much for the same reasons as the Performance section
above.  Bypassing the hypervisor eliminates scalability bottlenecks
(e.g. host network stack and bridge).


Probably not for the following cases:

1) kick/call

I disagree here because kick/call is actually very efficient!

VM1's irqfd is the ioeventfd for VM2.  When VM2 writes to the ioeventfd
there is a single lightweight vmexit which injects an interrupt into
VM1.  QEMU is not involved and the host kernel scheduler is not involved
so this is a low-latency operation.


Right, looks like I was wrong. But consider irqfd may do wakup which 
means scheduler is still needed.



I haven't tested this yet but the ioeventfd code looks like this will
work.


2) device IOTLB / IOMMU transaction (or any other case that backends needs
metadata from qemu).

Yes, this is the big weakness of vhost-user in general.  The IOMMU
feature doesn't offer good isolation

I think that's an implementation issue, not a protocol issue.



and even when it does, performance
will be an issue.

If the IOMMU mappings are dynamic - but they are mostly
static with e.g. dpdk, right?



   * Implement "Additional Device Resources over PCI" for shared memory,
 doorbells, and notifications instead of hardcoding a BAR with magic
 offsets into virtio-vhost-user:
 https://stefanha.github.io/virtio/vhost-user-slave.html#x1-2920007

Does this mean we need to standardize vhost-user protocol first?

Currently the draft spec says:

   This section relies on definitions from the Vhost-user Protocol [1].

   [1] 
https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/interop/vhost-user.txt;hb=HEAD

Michael: Is it okay to simply include this link?


It is OK to include normative and non-normative references,
they go in the introduction and then you refer to them
anywhere in the document.


I'm still reviewing the draft.  At some level, this is a general tunnel
feature, it can tunnel any protocol. That would be one way to
isolate it.


Right, but it should not be the main motivation, consider we can tunnel 
any protocol on top of ethernet too.





   * Implement the VRING_KICK eventfd - currently vhost-user slaves must be poll
 mode drivers.
   * Optimize VRING_CALL doorbell with ioeventfd to avoid QEMU exit.

The performance implication needs to be measured. It looks to me both kick
and call will introduce more latency form the point of guest.

I described the irqfd + ioeventfd approach above.  It should be faster
than virtio-net + bridge today.


   * vhost-user log feature
   * UUID config field for stable device identification regardless of PCI
 bus addresses.
   * vhost-user IOMMU and SLAVE_REQ_FD feature

So an assumption is the VM that implements vhost backends should be at least
as secure as vhost-user backend process on host. Could we have this
conclusion?

Yes.

Sadly the vhost-user IOMMU protocol feature does not provide isolation.
At the moment IOMMU is basically a layer of indirection (mapping) but
the vhost-user backend process still has full access to guest RAM :(.

An important feature would be to do the isolation in the qemu.
So trust the qemu running VM2 but not VM2 itself.


Agree, we'd better not consider 

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

2018-01-23 Thread Christian Borntraeger


On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell  
> wrote:
>> On 18 January 2018 at 02:01, Eduardo Habkost  wrote:
>>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
>>>
>>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into 
>>> staging (2018-01-16 17:36:39 +)
>>>
>>> are available in the Git repository at:
>>>
>>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
>>>
>>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
>>>
>>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
>>>
>>> 
>>> x86 queue, 2018-01-17
>>>
>>> Highlight: new CPU models that expose CPU features that guests
>>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
>>>
>>
>> Applied, thanks.
>>
>> -- PMM
>>
> 
> Hi,
> I was kind of clinging to [1] so far and had the expectation that all
> those would be wrapped up in 2.11.1 once ready.
> I see that the s390x changes are targeted to qemu-stable (well to
> admit I suggested so referring the article above).
> So I'd expected to see this series to show up on qemu-stable as well
> but haven't seen it so far.
> 
> Therefore I wanted to ask if there was a change of plans in that
> regard or if it needs just a few days more to see (part of) this
> series on qemu-stable and on its way into 2.11.1?
> 
> [1]: https://www.qemu.org/2018/01/04/spectre/

Adding Michael,

Yes, I think it makes sense to have the guest enablement for the spectre 
mitigations available in 2.11.1 for all architectures that provide it. 
(this queue for x86, Connies pending S390 patches, whatever Power
and arm will do).

Not sure about a 2.10.3?




[Qemu-devel] [PATCH v4 04/25] x86: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
v2:
  - fix conflict due to cortex-a57 change in aarch64 entry
in previous patch

CC: Eduardo Habkost 
---
 target/i386/cpu.h | 1 +
 tests/machine-none-test.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 30cc562..82c7381 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1568,6 +1568,7 @@ uint64_t cpu_get_tsc(CPUX86State *env);
 
 #define X86_CPU_TYPE_SUFFIX "-" TYPE_X86_CPU
 #define X86_CPU_TYPE_NAME(name) (name X86_CPU_TYPE_SUFFIX)
+#define CPU_RESOLVING_TYPE TYPE_X86_CPU
 
 #ifdef TARGET_X86_64
 #define TARGET_DEFAULT_CPU_TYPE X86_CPU_TYPE_NAME("qemu64")
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 06139f5..f4e00f5 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -26,6 +26,8 @@ static struct arch2cpu cpus_map[] = {
 /* tested targets list */
 { "arm", "cortex-a15" },
 { "aarch64", "cortex-a57" },
+{ "x86_64", "qemu64,apic-id=0" },
+{ "i386", "qemu32,apic-id=0" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v4 03/25] arm: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
thest would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
v2:
  - use cortex-a57 for aarch64 test (Andrew Jones )

CC: qemu-...@nongnu.org
CC: Peter Maydell 
CC: Andrew Jones 
---
 target/arm/cpu.h  | 1 +
 linux-user/main.c | 2 --
 tests/machine-none-test.c | 2 ++
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 9631670..f9fb141 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -2171,6 +2171,7 @@ static inline bool arm_excp_unmasked(CPUState *cs, 
unsigned int excp_idx,
 
 #define ARM_CPU_TYPE_SUFFIX "-" TYPE_ARM_CPU
 #define ARM_CPU_TYPE_NAME(name) (name ARM_CPU_TYPE_SUFFIX)
+#define CPU_RESOLVING_TYPE TYPE_ARM_CPU
 
 #define cpu_signal_handler cpu_arm_signal_handler
 #define cpu_list arm_cpu_list
diff --git a/linux-user/main.c b/linux-user/main.c
index 450eb3c..a35477e 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -4325,8 +4325,6 @@ int main(int argc, char **argv, char **envp)
 #else
 cpu_model = "qemu32";
 #endif
-#elif defined(TARGET_ARM)
-cpu_model = "any";
 #elif defined(TARGET_UNICORE32)
 cpu_model = "any";
 #elif defined(TARGET_M68K)
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 2eb13e8..06139f5 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -24,6 +24,8 @@ struct arch2cpu {
 
 static struct arch2cpu cpus_map[] = {
 /* tested targets list */
+{ "arm", "cortex-a15" },
+{ "aarch64", "cortex-a57" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




Re: [Qemu-devel] [PATCH v3 03/25] arm: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Andrew Jones
On Tue, Jan 23, 2018 at 09:08:02AM +0100, Igor Mammedov wrote:
> it will be used for providing to cpu name resolving class for
> parsing cpu model for system and user emulation code.
> 
> Along with change add target to null-machine test, so
> that when switch to CPU_RESOLVING_TYPE happens,
> thest would ensure that null-mchine usecase still works.
> 
> Signed-off-by: Igor Mammedov 
> ---
> CC: qemu-...@nongnu.org
> CC: Peter Maydell 
> CC: Andrew Jones 
> ---
>  target/arm/cpu.h  | 1 +
>  linux-user/main.c | 2 --
>  tests/machine-none-test.c | 2 ++
>  3 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 9631670..f9fb141 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -2171,6 +2171,7 @@ static inline bool arm_excp_unmasked(CPUState *cs, 
> unsigned int excp_idx,
>  
>  #define ARM_CPU_TYPE_SUFFIX "-" TYPE_ARM_CPU
>  #define ARM_CPU_TYPE_NAME(name) (name ARM_CPU_TYPE_SUFFIX)
> +#define CPU_RESOLVING_TYPE TYPE_ARM_CPU
>  
>  #define cpu_signal_handler cpu_arm_signal_handler
>  #define cpu_list arm_cpu_list
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 450eb3c..a35477e 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -4325,8 +4325,6 @@ int main(int argc, char **argv, char **envp)
>  #else
>  cpu_model = "qemu32";
>  #endif
> -#elif defined(TARGET_ARM)
> -cpu_model = "any";
>  #elif defined(TARGET_UNICORE32)
>  cpu_model = "any";
>  #elif defined(TARGET_M68K)
> diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
> index 2eb13e8..1b213ff 100644
> --- a/tests/machine-none-test.c
> +++ b/tests/machine-none-test.c
> @@ -24,6 +24,8 @@ struct arch2cpu {
>  
>  static struct arch2cpu cpus_map[] = {
>  /* tested targets list */
> +{ "arm", "cortex-a15" },
> +{ "aarch64", "cortex-a15" },

I understand that this doesn't matter for your purposes, but can we change
the aarch64 mapping to point to an aarch64 processor, e.g. cortex-a57,
instead?

Thanks,
drew

>  };
>  
>  static const char *get_cpu_model_by_arch(const char *arch)
> -- 
> 2.7.4
> 
> 



[Qemu-devel] [RFC PATCH v5 24/24] replay: don't drain/flush bdrv queue while RR is working

2018-01-23 Thread Pavel Dovgalyuk
In record/replay mode bdrv queue is controlled by replay mechanism.
It does not allow stopping the vm, saving or loading the snapshots
when bdrv queue is not empty. Therefore draining and flushing is unnecessary
(and may cause deadlocks in replay mode).
This patch disables bdrv_drain_all and bdrv_flush_all in replay mode.

Signed-off-by: Pavel Dovgalyuk 
---
 block/io.c |   22 ++
 cpus.c |2 --
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/block/io.c b/block/io.c
index 7ea4023..e773e68 100644
--- a/block/io.c
+++ b/block/io.c
@@ -31,6 +31,7 @@
 #include "qemu/cutils.h"
 #include "qapi/error.h"
 #include "qemu/error-report.h"
+#include "sysemu/replay.h"
 
 #define NOT_DONE 0x7fff /* used while emulated sync operation in progress 
*/
 
@@ -407,6 +408,13 @@ void bdrv_drain_all_begin(void)
 BdrvNextIterator it;
 GSList *aio_ctxs = NULL, *ctx;
 
+/* bdrv queue is managed by record/replay,
+   waiting for finishing the I/O requests may
+   be infinite */
+if (replay_events_enabled()) {
+return;
+}
+
 /* BDRV_POLL_WHILE() for a node can only be called from its own I/O thread
  * or the main loop AioContext. We potentially use BDRV_POLL_WHILE() on
  * nodes in several different AioContexts, so make sure we're in the main
@@ -458,6 +466,13 @@ void bdrv_drain_all_end(void)
 BlockDriverState *bs;
 BdrvNextIterator it;
 
+/* bdrv queue is managed by record/replay,
+   waiting for finishing the I/O requests may
+   be endless */
+if (replay_events_enabled()) {
+return;
+}
+
 for (bs = bdrv_first(&it); bs; bs = bdrv_next(&it)) {
 AioContext *aio_context = bdrv_get_aio_context(bs);
 
@@ -1839,6 +1854,13 @@ int bdrv_flush_all(void)
 BlockDriverState *bs = NULL;
 int result = 0;
 
+/* bdrv queue is managed by record/replay,
+   creating new flush request for stopping
+   the VM may break the determinism */
+if (replay_events_enabled()) {
+return result;
+}
+
 for (bs = bdrv_first(&it); bs; bs = bdrv_next(&it)) {
 AioContext *aio_context = bdrv_get_aio_context(bs);
 int ret;
diff --git a/cpus.c b/cpus.c
index a1f8808..e84f041 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1005,7 +1005,6 @@ static int do_vm_stop(RunState state)
 }
 
 bdrv_drain_all();
-replay_disable_events();
 ret = bdrv_flush_all();
 
 return ret;
@@ -1988,7 +1987,6 @@ int vm_prepare_start(void)
 qapi_event_send_stop(&error_abort);
 res = -1;
 } else {
-replay_enable_events();
 cpu_enable_ticks();
 runstate_set(RUN_STATE_RUNNING);
 vm_state_notify(1, RUN_STATE_RUNNING);




[Qemu-devel] [RFC PATCH v5 21/24] scripts/replay-dump.py: replay log dumper

2018-01-23 Thread Pavel Dovgalyuk
From: Alex Bennée 

This script is a debugging tool for looking through the contents of a
replay log file. It is incomplete but should fail gracefully at events
it doesn't understand.

It currently understands two different log formats as the audio
record/replay support was merged during since MTTCG. It was written to
help debug what has caused the BQL changes to break replay support.

Signed-off-by: Alex Bennée 

---
v2
  - yet another update to the log format
---
 scripts/replay-dump.py |  308 
 1 file changed, 308 insertions(+)
 create mode 100755 scripts/replay-dump.py

diff --git a/scripts/replay-dump.py b/scripts/replay-dump.py
new file mode 100755
index 000..203bb31
--- /dev/null
+++ b/scripts/replay-dump.py
@@ -0,0 +1,308 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+#
+# Dump the contents of a recorded execution stream
+#
+#  Copyright (c) 2017 Alex Bennée 
+#
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2 of the License, or (at your option) any later version.
+#
+# This library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this library; if not, see .
+
+import argparse
+import struct
+from collections import namedtuple
+
+# This mirrors some of the global replay state which some of the
+# stream loading refers to. Some decoders may read the next event so
+# we need handle that case. Calling reuse_event will ensure the next
+# event is read from the cache rather than advancing the file.
+
+class ReplayState(object):
+def __init__(self):
+self.event = -1
+self.event_count = 0
+self.already_read = False
+self.current_checkpoint = 0
+self.checkpoint = 0
+
+def set_event(self, ev):
+self.event = ev
+self.event_count += 1
+
+def get_event(self):
+self.already_read = False
+return self.event
+
+def reuse_event(self, ev):
+self.event = ev
+self.already_read = True
+
+def set_checkpoint(self):
+self.checkpoint = self.event - self.checkpoint_start
+
+def get_checkpoint(self):
+return self.checkpoint
+
+replay_state = ReplayState()
+
+# Simple read functions that mirror replay-internal.c
+# The file-stream is big-endian and manually written out a byte at a time.
+
+def read_byte(fin):
+"Read a single byte"
+return struct.unpack('>B', fin.read(1))[0]
+
+def read_event(fin):
+"Read a single byte event, but save some state"
+if replay_state.already_read:
+return replay_state.get_event()
+else:
+replay_state.set_event(read_byte(fin))
+return replay_state.event
+
+def read_word(fin):
+"Read a 16 bit word"
+return struct.unpack('>H', fin.read(2))[0]
+
+def read_dword(fin):
+"Read a 32 bit word"
+return struct.unpack('>I', fin.read(4))[0]
+
+def read_qword(fin):
+"Read a 64 bit word"
+return struct.unpack('>Q', fin.read(8))[0]
+
+# Generic decoder structure
+Decoder = namedtuple("Decoder", "eid name fn")
+
+def call_decode(table, index, dumpfile):
+"Search decode table for next step"
+decoder = next((d for d in table if d.eid == index), None)
+if not decoder:
+print "Could not decode index: %d" % (index)
+print "Entry is: %s" % (decoder)
+print "Decode Table is:\n%s" % (table)
+return False
+else:
+return decoder.fn(decoder.eid, decoder.name, dumpfile)
+
+# Print event
+def print_event(eid, name, string=None, event_count=None):
+"Print event with count"
+if not event_count:
+event_count = replay_state.event_count
+
+if string:
+print "%d:%s(%d) %s" % (event_count, name, eid, string)
+else:
+print "%d:%s(%d)" % (event_count, name, eid)
+
+
+# Decoders for each event type
+
+def decode_unimp(eid, name, _unused_dumpfile):
+"Unimplimented decoder, will trigger exit"
+print "%s not handled - will now stop" % (name)
+return False
+
+# Checkpoint decoder
+def swallow_async_qword(eid, name, dumpfile):
+"Swallow a qword of data without looking at it"
+step_id = read_qword(dumpfile)
+print "  %s(%d) @ %d" % (name, eid, step_id)
+return True
+
+async_decode_table = [ Decoder(0, "REPLAY_ASYNC_EVENT_BH", 
swallow_async_qword),
+   Decoder(1, "REPLAY_ASYNC_INPUT", decode_unimp),
+   Decoder(2, "REPLAY_ASYNC_INPUT_SYNC", decode_unimp),
+   Decoder(3, "REPLAY_ASYNC_CHAR_READ", decode_unimp),
+   Decoder(4, "REPLAY_ASYN

[Qemu-devel] [RFC PATCH v5 23/24] replay: save vmstate of the asynchronous events

2018-01-23 Thread Pavel Dovgalyuk
This patch fixes saving and loading the snapshots in the replay mode.
It is required for the snapshots created in the moment when the header
of the asynchronous event is read. This information was not saved in
the snapshot. After loading the vmstate replay continued with the file offset
passed the event header. The event header is lost in this case and replay
hangs.

Signed-off-by: Pavel Dovgalyuk 
---
 replay/replay-events.c   |   44 +---
 replay/replay-internal.h |6 ++
 replay/replay-snapshot.c |3 +++
 3 files changed, 30 insertions(+), 23 deletions(-)

diff --git a/replay/replay-events.c b/replay/replay-events.c
index 18d769f..29c6185 100644
--- a/replay/replay-events.c
+++ b/replay/replay-events.c
@@ -27,10 +27,6 @@ typedef struct Event {
 } Event;
 
 static QTAILQ_HEAD(, Event) events_list = QTAILQ_HEAD_INITIALIZER(events_list);
-static unsigned int read_event_kind = -1;
-static uint64_t read_id = -1;
-static int read_checkpoint = -1;
-
 static bool events_enabled;
 
 /* Functions */
@@ -217,58 +213,60 @@ void replay_save_events(int checkpoint)
 static Event *replay_read_event(int checkpoint)
 {
 Event *event;
-if (read_event_kind == -1) {
-read_checkpoint = replay_get_byte();
-read_event_kind = replay_get_byte();
-read_id = -1;
+if (replay_state.read_event_kind == -1) {
+replay_state.read_event_checkpoint = replay_get_byte();
+replay_state.read_event_kind = replay_get_byte();
+replay_state.read_event_id = -1;
 replay_check_error();
 }
 
-if (checkpoint != read_checkpoint) {
+if (checkpoint != replay_state.read_event_checkpoint) {
 return NULL;
 }
 
 /* Events that has not to be in the queue */
-switch (read_event_kind) {
+switch (replay_state.read_event_kind) {
 case REPLAY_ASYNC_EVENT_BH:
-if (read_id == -1) {
-read_id = replay_get_qword();
+if (replay_state.read_event_id == -1) {
+replay_state.read_event_id = replay_get_qword();
 }
 break;
 case REPLAY_ASYNC_EVENT_INPUT:
 event = g_malloc0(sizeof(Event));
-event->event_kind = read_event_kind;
+event->event_kind = replay_state.read_event_kind;
 event->opaque = replay_read_input_event();
 return event;
 case REPLAY_ASYNC_EVENT_INPUT_SYNC:
 event = g_malloc0(sizeof(Event));
-event->event_kind = read_event_kind;
+event->event_kind = replay_state.read_event_kind;
 event->opaque = 0;
 return event;
 case REPLAY_ASYNC_EVENT_CHAR_READ:
 event = g_malloc0(sizeof(Event));
-event->event_kind = read_event_kind;
+event->event_kind = replay_state.read_event_kind;
 event->opaque = replay_event_char_read_load();
 return event;
 case REPLAY_ASYNC_EVENT_BLOCK:
-if (read_id == -1) {
-read_id = replay_get_qword();
+if (replay_state.read_event_id == -1) {
+replay_state.read_event_id = replay_get_qword();
 }
 break;
 case REPLAY_ASYNC_EVENT_NET:
 event = g_malloc0(sizeof(Event));
-event->event_kind = read_event_kind;
+event->event_kind = replay_state.read_event_kind;
 event->opaque = replay_event_net_load();
 return event;
 default:
-error_report("Unknown ID %d of replay event", read_event_kind);
+error_report("Unknown ID %d of replay event",
+replay_state.read_event_kind);
 exit(1);
 break;
 }
 
 QTAILQ_FOREACH(event, &events_list, events) {
-if (event->event_kind == read_event_kind
-&& (read_id == -1 || read_id == event->id)) {
+if (event->event_kind == replay_state.read_event_kind
+&& (replay_state.read_event_id == -1
+|| replay_state.read_event_id == event->id)) {
 break;
 }
 }
@@ -293,7 +291,7 @@ void replay_read_events(int checkpoint)
 break;
 }
 replay_finish_event();
-read_event_kind = -1;
+replay_state.read_event_kind = -1;
 replay_run_event(event);
 
 g_free(event);
@@ -302,7 +300,7 @@ void replay_read_events(int checkpoint)
 
 void replay_init_events(void)
 {
-read_event_kind = -1;
+replay_state.read_event_kind = -1;
 }
 
 void replay_finish_events(void)
diff --git a/replay/replay-internal.h b/replay/replay-internal.h
index f5f8e96..bace4c2 100644
--- a/replay/replay-internal.h
+++ b/replay/replay-internal.h
@@ -80,6 +80,12 @@ typedef struct ReplayState {
 uint64_t block_request_id;
 /*! Prior value of the host clock */
 uint64_t host_clock_last;
+/*! Asynchronous event type read from the log */
+int32_t read_event_kind;
+/*! Asynchronous event id read from the log */
+uint64_t read_event_id;
+/*! Asynchronous event checkpoint id read from the log */
+int32_t read_event_checkpoint

[Qemu-devel] [RFC PATCH v5 19/24] replay: check return values of fwrite

2018-01-23 Thread Pavel Dovgalyuk
This patch adds error reporting when fwrite cannot completely
save the buffer to the file.

Signed-off-by: Pavel Dovgalyuk 

--

v3: also check putc() return value
---
 replay/replay-internal.c |   17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/replay/replay-internal.c b/replay/replay-internal.c
index a1a7686..1034d8f 100644
--- a/replay/replay-internal.c
+++ b/replay/replay-internal.c
@@ -24,12 +24,23 @@
 static QemuMutex lock;
 
 /* File for replay writing */
+static bool write_error;
 FILE *replay_file;
 
+static void replay_write_error(void)
+{
+if (!write_error) {
+error_report("replay write error");
+write_error = true;
+}
+}
+
 void replay_put_byte(uint8_t byte)
 {
 if (replay_file) {
-putc(byte, replay_file);
+if (putc(byte, replay_file) == EOF) {
+replay_write_error();
+}
 }
 }
 
@@ -62,7 +73,9 @@ void replay_put_array(const uint8_t *buf, size_t size)
 {
 if (replay_file) {
 replay_put_dword(size);
-fwrite(buf, 1, size, replay_file);
+if (fwrite(buf, 1, size, replay_file) != size) {
+replay_write_error();
+}
 }
 }
 




[Qemu-devel] [RFC PATCH v5 22/24] replay: don't process async events when warping the clock

2018-01-23 Thread Pavel Dovgalyuk
Virtual clock is warped from iothread and vcpu thread. When the hardware
events associated with warp checkpoint, then interrupt delivering may be
non-deterministic if checkpoint is processed in different threads in record
and replay.
This patch disables event processing for clock warp checkpoint and leaves
all hardware events to other checkpoints (e.g., virtual clock).

Signed-off-by: Pavel Dovgalyuk 

--

v4: added assert for replay_save_events function
---
 replay/replay-events.c |1 +
 replay/replay.c|7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/replay/replay-events.c b/replay/replay-events.c
index a941efb..18d769f 100644
--- a/replay/replay-events.c
+++ b/replay/replay-events.c
@@ -204,6 +204,7 @@ static void replay_save_event(Event *event, int checkpoint)
 /* Called with replay mutex locked */
 void replay_save_events(int checkpoint)
 {
+assert(checkpoint != CHECKPOINT_CLOCK_WARP_START);
 while (!QTAILQ_EMPTY(&events_list)) {
 Event *event = QTAILQ_FIRST(&events_list);
 replay_save_event(event, checkpoint);
diff --git a/replay/replay.c b/replay/replay.c
index c676dd4..e3794fc 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -211,7 +211,12 @@ bool replay_checkpoint(ReplayCheckpoint checkpoint)
 } else if (replay_mode == REPLAY_MODE_RECORD) {
 g_assert(replay_mutex_locked());
 replay_put_event(EVENT_CHECKPOINT + checkpoint);
-replay_save_events(checkpoint);
+/* This checkpoint belongs to several threads.
+   Processing events from different threads is
+   non-deterministic */
+if (checkpoint != CHECKPOINT_CLOCK_WARP_START) {
+replay_save_events(checkpoint);
+}
 res = true;
 }
 out:




[Qemu-devel] [RFC PATCH v5 18/24] replay: don't destroy mutex at exit

2018-01-23 Thread Pavel Dovgalyuk
Replay mutex is held by vCPU thread and destroy function is called
from atexit of the main thread. Therefore we cannot destroy it safely.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Paolo Bonzini 
---
 replay/replay.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/replay/replay.c b/replay/replay.c
index a3ab3bb..585c5de 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -356,7 +356,6 @@ void replay_finish(void)
 replay_snapshot = NULL;
 
 replay_finish_events();
-replay_mutex_destroy();
 }
 
 void replay_add_blocker(Error *reason)




[Qemu-devel] [RFC PATCH v5 15/24] replay/replay-internal.c: track holding of replay_lock

2018-01-23 Thread Pavel Dovgalyuk
From: Alex Bennée 

This is modelled after the iothread mutex lock. We keep a TLS flag to
indicate when that thread has acquired the lock and assert we don't
double-lock or release when we shouldn't have.

Signed-off-by: Alex Bennée 
Tested-by: Pavel Dovgalyuk 
---
 replay/replay-internal.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/replay/replay-internal.c b/replay/replay-internal.c
index fca8514..157c863 100644
--- a/replay/replay-internal.c
+++ b/replay/replay-internal.c
@@ -179,13 +179,24 @@ void replay_mutex_destroy(void)
 qemu_mutex_destroy(&lock);
 }
 
+static __thread bool replay_locked;
+
+static bool replay_mutex_locked(void)
+{
+return replay_locked;
+}
+
 void replay_mutex_lock(void)
 {
+g_assert(!replay_mutex_locked());
 qemu_mutex_lock(&lock);
+replay_locked = true;
 }
 
 void replay_mutex_unlock(void)
 {
+g_assert(replay_mutex_locked());
+replay_locked = false;
 qemu_mutex_unlock(&lock);
 }
 




[Qemu-devel] [RFC PATCH v5 20/24] replay: avoid recursive call of checkpoints

2018-01-23 Thread Pavel Dovgalyuk
This patch adds a flag which denies recursive call of replay_checkpoint
function. Checkpoints may be accompanied by the hardware events. When event
is processed, virtual device may invoke timer modification functions that
also invoke the checkpoint function. This leads to infinite loop.

Signed-off-by: Pavel Dovgalyuk 
---
 replay/replay.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/replay/replay.c b/replay/replay.c
index 585c5de..c676dd4 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -176,13 +176,24 @@ void replay_shutdown_request(ShutdownCause cause)
 bool replay_checkpoint(ReplayCheckpoint checkpoint)
 {
 bool res = false;
+static bool in_checkpoint;
 assert(EVENT_CHECKPOINT + checkpoint <= EVENT_CHECKPOINT_LAST);
-replay_save_instructions();
 
 if (!replay_file) {
 return true;
 }
 
+if (in_checkpoint) {
+/* If we are already in checkpoint, then there is no need
+   for additional synchronization.
+   Recursion occurs when HW event modifies timers.
+   Timer modification may invoke the checkpoint and
+   proceed to recursion. */
+return true;
+}
+in_checkpoint = true;
+
+replay_save_instructions();
 
 if (replay_mode == REPLAY_MODE_PLAY) {
 g_assert(replay_mutex_locked());
@@ -204,6 +215,7 @@ bool replay_checkpoint(ReplayCheckpoint checkpoint)
 res = true;
 }
 out:
+in_checkpoint = false;
 return res;
 }
 




[Qemu-devel] [RFC PATCH v5 13/24] kvm: remove BQL lock/unlock

2018-01-23 Thread Pavel Dovgalyuk
BQL now is used only for waiting for IO events.
This patch also removes lock/unlock from kvm module.

Signed-off-by: Pavel Dovgalyuk 
---
 accel/kvm/kvm-all.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 9628512..d708c7f 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -1861,7 +1861,6 @@ int kvm_cpu_exec(CPUState *cpu)
 return EXCP_HLT;
 }
 
-qemu_mutex_unlock_iothread();
 cpu_exec_start(cpu);
 do {
 MemTxAttrs attrs;
@@ -1992,7 +1991,6 @@ int kvm_cpu_exec(CPUState *cpu)
 } while (ret == 0);
 
 cpu_exec_end(cpu);
-qemu_mutex_lock_iothread();
 
 if (ret < 0) {
 cpu_dump_state(cpu, stderr, fprintf, CPU_DUMP_CODE);




[Qemu-devel] [RFC PATCH v5 14/24] replay/replay.c: bump REPLAY_VERSION again

2018-01-23 Thread Pavel Dovgalyuk
From: Alex Bennée 

This time commit 802f045a5f61b781df55e4492d896b4d20503ba7 broke the
replay file format. Also add a comment about this to
replay-internal.h.

Signed-off-by: Alex Bennée 
Reviewed-off-by: Pavel Dovgalyuk 
Acked-by: Paolo Bonzini 
---
 replay/replay-internal.h |2 +-
 replay/replay.c  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/replay/replay-internal.h b/replay/replay-internal.h
index be96d7e..8e4c701 100644
--- a/replay/replay-internal.h
+++ b/replay/replay-internal.h
@@ -12,7 +12,7 @@
  *
  */
 
-
+/* Any changes to order/number of events will need to bump REPLAY_VERSION */
 enum ReplayEvents {
 /* for instruction event */
 EVENT_INSTRUCTION,
diff --git a/replay/replay.c b/replay/replay.c
index ff58a5a..4f24498 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -22,7 +22,7 @@
 
 /* Current version of the replay mechanism.
Increase it when file format changes. */
-#define REPLAY_VERSION  0xe02006
+#define REPLAY_VERSION  0xe02007
 /* Size of replay log header */
 #define HEADER_SIZE (sizeof(uint32_t) + sizeof(uint64_t))
 




[Qemu-devel] [RFC PATCH v5 11/24] cpus: push BQL lock to qemu_*_wait_io_event

2018-01-23 Thread Pavel Dovgalyuk
From: Alex Bennée 

We only really need to grab the lock for initial setup (so we don't
race with the thread-spawning thread). After that we can drop the lock
for the whole main loop and only grab it for waiting for IO events.

There is a slight wrinkle for the round-robin TCG thread as we also
expire timers which needs to be done under BQL as they are in the
main-loop.

This is stage one of reducing the lock impact as we can drop the
requirement of implicit BQL for async work and only grab the lock when
we need to sleep on the cpu->halt_cond.

Signed-off-by: Alex Bennée 
Signed-off-by: Pavel Dovgalyuk 
---
 accel/kvm/kvm-all.c |1 -
 cpus.c  |   29 +
 2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 071f4f5..9628512 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -1863,7 +1863,6 @@ int kvm_cpu_exec(CPUState *cpu)
 
 qemu_mutex_unlock_iothread();
 cpu_exec_start(cpu);
-
 do {
 MemTxAttrs attrs;
 
diff --git a/cpus.c b/cpus.c
index 2cb0af9..577c764 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1141,6 +1141,7 @@ static void qemu_wait_io_event_common(CPUState *cpu)
 
 static void qemu_tcg_rr_wait_io_event(CPUState *cpu)
 {
+qemu_mutex_lock_iothread();
 while (all_cpu_threads_idle()) {
 stop_tcg_kick_timer();
 qemu_cond_wait(cpu->halt_cond, &qemu_global_mutex);
@@ -1149,10 +1150,13 @@ static void qemu_tcg_rr_wait_io_event(CPUState *cpu)
 start_tcg_kick_timer();
 
 qemu_wait_io_event_common(cpu);
+qemu_mutex_unlock_iothread();
 }
 
 static void qemu_wait_io_event(CPUState *cpu)
 {
+qemu_mutex_lock_iothread();
+
 while (cpu_thread_is_idle(cpu)) {
 qemu_cond_wait(cpu->halt_cond, &qemu_global_mutex);
 }
@@ -1164,6 +1168,7 @@ static void qemu_wait_io_event(CPUState *cpu)
 }
 #endif
 qemu_wait_io_event_common(cpu);
+qemu_mutex_unlock_iothread();
 }
 
 static void *qemu_kvm_cpu_thread_fn(void *arg)
@@ -1189,6 +1194,8 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
 
 /* signal CPU creation */
 cpu->created = true;
+qemu_mutex_unlock_iothread();
+
 qemu_cond_signal(&qemu_cpu_cond);
 
 do {
@@ -1204,7 +1211,6 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
 qemu_kvm_destroy_vcpu(cpu);
 cpu->created = false;
 qemu_cond_signal(&qemu_cpu_cond);
-qemu_mutex_unlock_iothread();
 return NULL;
 }
 
@@ -1231,10 +1237,10 @@ static void *qemu_dummy_cpu_thread_fn(void *arg)
 
 /* signal CPU creation */
 cpu->created = true;
+qemu_mutex_unlock_iothread();
 qemu_cond_signal(&qemu_cpu_cond);
 
 while (1) {
-qemu_mutex_unlock_iothread();
 do {
 int sig;
 r = sigwait(&waitset, &sig);
@@ -1243,7 +1249,6 @@ static void *qemu_dummy_cpu_thread_fn(void *arg)
 perror("sigwait");
 exit(1);
 }
-qemu_mutex_lock_iothread();
 qemu_wait_io_event(cpu);
 }
 
@@ -1333,11 +1338,9 @@ static int tcg_cpu_exec(CPUState *cpu)
 #ifdef CONFIG_PROFILER
 ti = profile_getclock();
 #endif
-qemu_mutex_unlock_iothread();
 cpu_exec_start(cpu);
 ret = cpu_exec(cpu);
 cpu_exec_end(cpu);
-qemu_mutex_lock_iothread();
 #ifdef CONFIG_PROFILER
 tcg_time += profile_getclock() - ti;
 #endif
@@ -1397,6 +1400,7 @@ static void *qemu_tcg_rr_cpu_thread_fn(void *arg)
 qemu_wait_io_event_common(cpu);
 }
 }
+qemu_mutex_unlock_iothread();
 
 start_tcg_kick_timer();
 
@@ -1406,6 +1410,8 @@ static void *qemu_tcg_rr_cpu_thread_fn(void *arg)
 cpu->exit_request = 1;
 
 while (1) {
+qemu_mutex_lock_iothread();
+
 /* Account partial waits to QEMU_CLOCK_VIRTUAL.  */
 qemu_account_warp_timer();
 
@@ -1414,6 +1420,8 @@ static void *qemu_tcg_rr_cpu_thread_fn(void *arg)
  */
 handle_icount_deadline();
 
+qemu_mutex_unlock_iothread();
+
 if (!cpu) {
 cpu = first_cpu;
 }
@@ -1439,9 +1447,7 @@ static void *qemu_tcg_rr_cpu_thread_fn(void *arg)
 cpu_handle_guest_debug(cpu);
 break;
 } else if (r == EXCP_ATOMIC) {
-qemu_mutex_unlock_iothread();
 cpu_exec_step_atomic(cpu);
-qemu_mutex_lock_iothread();
 break;
 }
 } else if (cpu->stop) {
@@ -1482,6 +1488,7 @@ static void *qemu_hax_cpu_thread_fn(void *arg)
 current_cpu = cpu;
 
 hax_init_vcpu(cpu);
+qemu_mutex_unlock_iothread();
 qemu_cond_signal(&qemu_cpu_cond);
 
 while (1) {
@@ -1518,8 +1525,9 @@ static void *qemu_hvf_cpu_thread_fn(void *arg)
 
 hvf_init_vcpu(cpu);
 
-/* signal CPU creation */
 cpu->created = true;
+qemu_mutex_unlock_iothread();
+/* signal CPU creation */
 qemu_cond_signal(&qemu_cpu_cond);
 
 do {
@@ -1535,7 +1543,6 @@ static void *qem

[Qemu-devel] [RFC PATCH v5 16/24] replay: make locking visible outside replay code

2018-01-23 Thread Pavel Dovgalyuk
From: Alex Bennée 

The replay_mutex_lock/unlock/locked functions are now going to be used
for ensuring lock-step behaviour between the two threads. Make them
public API functions and also provide stubs for non-QEMU builds on
common paths.

Signed-off-by: Alex Bennée 
Tested-by: Pavel Dovgalyuk 
---
 include/sysemu/replay.h  |   14 ++
 replay/replay-internal.c |9 -
 replay/replay-internal.h |5 ++---
 stubs/replay.c   |   15 +++
 4 files changed, 35 insertions(+), 8 deletions(-)

diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index b86d6bb..9973849 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -47,6 +47,20 @@ extern ReplayMode replay_mode;
 /* Name of the initial VM snapshot */
 extern char *replay_snapshot;
 
+/* Replay locking
+ *
+ * The locks are needed to protect the shared structures and log file
+ * when doing record/replay. They also are the main sync-point between
+ * the main-loop thread and the vCPU thread. This was a role
+ * previously filled by the BQL which has been busy trying to reduce
+ * its impact across the code. This ensures blocks of events stay
+ * sequential and reproducible.
+ */
+
+void replay_mutex_lock(void);
+void replay_mutex_unlock(void);
+bool replay_mutex_locked(void);
+
 /* Replay process control functions */
 
 /*! Enables recording or saving event log with specified parameters */
diff --git a/replay/replay-internal.c b/replay/replay-internal.c
index 157c863..a9a6a64 100644
--- a/replay/replay-internal.c
+++ b/replay/replay-internal.c
@@ -169,6 +169,8 @@ void replay_finish_event(void)
 replay_fetch_data_kind();
 }
 
+static __thread bool replay_locked;
+
 void replay_mutex_init(void)
 {
 qemu_mutex_init(&lock);
@@ -179,9 +181,7 @@ void replay_mutex_destroy(void)
 qemu_mutex_destroy(&lock);
 }
 
-static __thread bool replay_locked;
-
-static bool replay_mutex_locked(void)
+bool replay_mutex_locked(void)
 {
 return replay_locked;
 }
@@ -204,7 +204,7 @@ void replay_mutex_unlock(void)
 void replay_save_instructions(void)
 {
 if (replay_file && replay_mode == REPLAY_MODE_RECORD) {
-replay_mutex_lock();
+g_assert(replay_mutex_locked());
 int diff = (int)(replay_get_current_step() - 
replay_state.current_step);
 
 /* Time can only go forward */
@@ -215,6 +215,5 @@ void replay_save_instructions(void)
 replay_put_dword(diff);
 replay_state.current_step += diff;
 }
-replay_mutex_unlock();
 }
 }
diff --git a/replay/replay-internal.h b/replay/replay-internal.h
index 8e4c701..f5f8e96 100644
--- a/replay/replay-internal.h
+++ b/replay/replay-internal.h
@@ -100,12 +100,11 @@ int64_t replay_get_qword(void);
 void replay_get_array(uint8_t *buf, size_t *size);
 void replay_get_array_alloc(uint8_t **buf, size_t *size);
 
-/* Mutex functions for protecting replay log file */
+/* Mutex functions for protecting replay log file and ensuring
+ * synchronisation between vCPU and main-loop threads. */
 
 void replay_mutex_init(void);
 void replay_mutex_destroy(void);
-void replay_mutex_lock(void);
-void replay_mutex_unlock(void);
 
 /*! Checks error status of the file. */
 void replay_check_error(void);
diff --git a/stubs/replay.c b/stubs/replay.c
index 9991ee5..cb050ef 100644
--- a/stubs/replay.c
+++ b/stubs/replay.c
@@ -73,3 +73,18 @@ uint64_t blkreplay_next_id(void)
 {
 return 0;
 }
+
+void replay_mutex_lock(void)
+{
+abort();
+}
+
+void replay_mutex_unlock(void)
+{
+abort();
+}
+
+bool replay_mutex_locked(void)
+{
+return false;
+}




[Qemu-devel] [RFC PATCH v5 12/24] hax: remove BQL lock/unlock

2018-01-23 Thread Pavel Dovgalyuk
BQL now is used only for waiting for IO events.
This patch also removes lock/unlock from hax module.

Signed-off-by: Pavel Dovgalyuk 
---
 target/i386/hax-all.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/target/i386/hax-all.c b/target/i386/hax-all.c
index 934ec4a..54b1fc7 100644
--- a/target/i386/hax-all.c
+++ b/target/i386/hax-all.c
@@ -513,11 +513,9 @@ static int hax_vcpu_hax_exec(CPUArchState *env)
 
 hax_vcpu_interrupt(env);
 
-qemu_mutex_unlock_iothread();
 cpu_exec_start(cpu);
 hax_ret = hax_vcpu_run(vcpu);
 cpu_exec_end(cpu);
-qemu_mutex_lock_iothread();
 
 /* Simply continue the vcpu_run if system call interrupted */
 if (hax_ret == -EINTR || hax_ret == -EAGAIN) {




[Qemu-devel] [RFC PATCH v5 17/24] replay: push replay_mutex_lock up the call tree

2018-01-23 Thread Pavel Dovgalyuk
From: Alex Bennée 

Now instead of using the replay_lock to guard the output of the log we
now use it to protect the whole execution section. This replaces what
the BQL used to do when it was held during TCG execution.

We also introduce some rules for locking order - mainly that you
cannot take the replay_mutex while holding the BQL. This leads to some
slight sophistry during start-up and extending the
replay_mutex_destroy function to unlock the mutex without checking
for the BQL condition so it can be cleanly dropped in the non-replay
case.

Signed-off-by: Alex Bennée 
Tested-by: Pavel Dovgalyuk 

--

v2: updated replay_mutex_lock/unlock functions as suggested by Paolo Bonzini
updated docs
---
 cpus.c   |   16 
 docs/replay.txt  |   22 ++
 include/sysemu/replay.h  |2 ++
 replay/replay-char.c |   21 -
 replay/replay-events.c   |   18 +-
 replay/replay-internal.c |   33 +++--
 replay/replay-time.c |   10 +-
 replay/replay.c  |   38 ++
 util/main-loop.c |   17 +
 vl.c |2 ++
 10 files changed, 114 insertions(+), 65 deletions(-)

diff --git a/cpus.c b/cpus.c
index 577c764..a1f8808 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1309,6 +1309,8 @@ static void prepare_icount_for_run(CPUState *cpu)
 insns_left = MIN(0x, cpu->icount_budget);
 cpu->icount_decr.u16.low = insns_left;
 cpu->icount_extra = cpu->icount_budget - insns_left;
+
+replay_mutex_lock();
 }
 }
 
@@ -1324,6 +1326,8 @@ static void process_icount_data(CPUState *cpu)
 cpu->icount_budget = 0;
 
 replay_account_executed_instructions();
+
+replay_mutex_unlock();
 }
 }
 
@@ -1410,6 +1414,7 @@ static void *qemu_tcg_rr_cpu_thread_fn(void *arg)
 cpu->exit_request = 1;
 
 while (1) {
+replay_mutex_lock();
 qemu_mutex_lock_iothread();
 
 /* Account partial waits to QEMU_CLOCK_VIRTUAL.  */
@@ -1422,6 +1427,8 @@ static void *qemu_tcg_rr_cpu_thread_fn(void *arg)
 
 qemu_mutex_unlock_iothread();
 
+replay_mutex_unlock();
+
 if (!cpu) {
 cpu = first_cpu;
 }
@@ -1727,12 +1734,21 @@ void pause_all_vcpus(void)
 }
 }
 
+/* We need to drop the replay_lock so any vCPU threads woken up
+ * can finish their replay tasks
+ */
+replay_mutex_unlock();
+
 while (!all_vcpus_paused()) {
 qemu_cond_wait(&qemu_pause_cond, &qemu_global_mutex);
 CPU_FOREACH(cpu) {
 qemu_cpu_kick(cpu);
 }
 }
+
+qemu_mutex_unlock_iothread();
+replay_mutex_lock();
+qemu_mutex_lock_iothread();
 }
 
 void cpu_resume(CPUState *cpu)
diff --git a/docs/replay.txt b/docs/replay.txt
index c52407f..959633e 100644
--- a/docs/replay.txt
+++ b/docs/replay.txt
@@ -49,6 +49,28 @@ Modifications of qemu include:
  * recording/replaying user input (mouse and keyboard)
  * adding internal checkpoints for cpu and io synchronization
 
+Locking and thread synchronisation
+--
+
+Previously the synchronisation of the main thread and the vCPU thread
+was ensured by the holding of the BQL. However the trend has been to
+reduce the time the BQL was held across the system including under TCG
+system emulation. As it is important that batches of events are kept
+in sequence (e.g. expiring timers and checkpoints in the main thread
+while instruction checkpoints are written by the vCPU thread) we need
+another lock to keep things in lock-step. This role is now handled by
+the replay_mutex_lock. It used to be held only for each event being
+written but now it is held for a whole execution period. This results
+in a deterministic ping-pong between the two main threads.
+
+As the BQL is now a finer grained lock than the replay_lock it is almost
+certainly a bug, and a source of deadlocks, to take the
+replay_mutex_lock while the BQL is held. This is enforced by an assert.
+While the unlocks are usually in the reverse order, this is not
+necessary; you can drop the replay_lock while holding the BQL, without
+doing a more complicated unlock_iothread/replay_unlock/lock_iothread
+sequence.
+
 Non-deterministic events
 
 
diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index 9973849..d026b28 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -63,6 +63,8 @@ bool replay_mutex_locked(void);
 
 /* Replay process control functions */
 
+/*! Enables and take replay locks (even if we don't use it) */
+void replay_init_locks(void);
 /*! Enables recording or saving event log with specified parameters */
 void replay_configure(struct QemuOpts *opts);
 /*! Initializes timers used for snapshotting and enables events recording */
diff --git a/replay/replay-char.c b/replay/replay-char.c
index cbf7c04..736cc8c 1007

[Qemu-devel] [RFC PATCH v5 09/24] replay: save prior value of the host clock

2018-01-23 Thread Pavel Dovgalyuk
This patch adds saving/restoring of the host clock field 'last'.
It is used in host clock calculation and therefore clock may
become incorrect when using restored vmstate.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Paolo Bonzini 
---
 include/qemu/timer.h |   14 ++
 replay/replay-internal.h |2 ++
 replay/replay-snapshot.c |3 +++
 util/qemu-timer.c|   12 
 4 files changed, 31 insertions(+)

diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index 1b518bc..a610a17 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -251,6 +251,20 @@ bool qemu_clock_run_timers(QEMUClockType type);
  */
 bool qemu_clock_run_all_timers(void);
 
+/**
+ * qemu_clock_get_last:
+ *
+ * Returns last clock query time.
+ */
+uint64_t qemu_clock_get_last(QEMUClockType type);
+/**
+ * qemu_clock_set_last:
+ *
+ * Sets last clock query time.
+ */
+void qemu_clock_set_last(QEMUClockType type, uint64_t last);
+
+
 /*
  * QEMUTimerList
  */
diff --git a/replay/replay-internal.h b/replay/replay-internal.h
index 3ebb199..be96d7e 100644
--- a/replay/replay-internal.h
+++ b/replay/replay-internal.h
@@ -78,6 +78,8 @@ typedef struct ReplayState {
 This counter is global, because requests from different
 block devices should not get overlapping ids. */
 uint64_t block_request_id;
+/*! Prior value of the host clock */
+uint64_t host_clock_last;
 } ReplayState;
 extern ReplayState replay_state;
 
diff --git a/replay/replay-snapshot.c b/replay/replay-snapshot.c
index 7075986..e0b2204 100644
--- a/replay/replay-snapshot.c
+++ b/replay/replay-snapshot.c
@@ -25,6 +25,7 @@ static int replay_pre_save(void *opaque)
 {
 ReplayState *state = opaque;
 state->file_offset = ftell(replay_file);
+state->host_clock_last = qemu_clock_get_last(QEMU_CLOCK_HOST);
 
 return 0;
 }
@@ -33,6 +34,7 @@ static int replay_post_load(void *opaque, int version_id)
 {
 ReplayState *state = opaque;
 fseek(replay_file, state->file_offset, SEEK_SET);
+qemu_clock_set_last(QEMU_CLOCK_HOST, state->host_clock_last);
 /* If this was a vmstate, saved in recording mode,
we need to initialize replay data fields. */
 replay_fetch_data_kind();
@@ -54,6 +56,7 @@ static const VMStateDescription vmstate_replay = {
 VMSTATE_UINT32(has_unread_data, ReplayState),
 VMSTATE_UINT64(file_offset, ReplayState),
 VMSTATE_UINT64(block_request_id, ReplayState),
+VMSTATE_UINT64(host_clock_last, ReplayState),
 VMSTATE_END_OF_LIST()
 },
 };
diff --git a/util/qemu-timer.c b/util/qemu-timer.c
index 82d5650..2ed1bf2 100644
--- a/util/qemu-timer.c
+++ b/util/qemu-timer.c
@@ -622,6 +622,18 @@ int64_t qemu_clock_get_ns(QEMUClockType type)
 }
 }
 
+uint64_t qemu_clock_get_last(QEMUClockType type)
+{
+QEMUClock *clock = qemu_clock_ptr(type);
+return clock->last;
+}
+
+void qemu_clock_set_last(QEMUClockType type, uint64_t last)
+{
+QEMUClock *clock = qemu_clock_ptr(type);
+clock->last = last;
+}
+
 void qemu_clock_register_reset_notifier(QEMUClockType type,
 Notifier *notifier)
 {




[Qemu-devel] [RFC PATCH v5 08/24] replay: added replay log format description

2018-01-23 Thread Pavel Dovgalyuk
From: Pavel Dovgalyuk 

This patch adds description of the replay log file format
into the docs/replay.txt.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Paolo Bonzini 
---
 docs/replay.txt |   69 +++
 1 file changed, 69 insertions(+)

diff --git a/docs/replay.txt b/docs/replay.txt
index 486c1e0..c52407f 100644
--- a/docs/replay.txt
+++ b/docs/replay.txt
@@ -232,3 +232,72 @@ Audio devices
 Audio data is recorded and replay automatically. The command line for recording
 and replaying must contain identical specifications of audio hardware, e.g.:
  -soundhw ac97
+
+Replay log format
+-
+
+Record/replay log consits of the header and the sequence of execution
+events. The header includes 4-byte replay version id and 8-byte reserved
+field. Version is updated every time replay log format changes to prevent
+using replay log created by another build of qemu.
+
+The sequence of the events describes virtual machine state changes.
+It includes all non-deterministic inputs of VM, synchronization marks and
+instruction counts used to correctly inject inputs at replay.
+
+Synchronization marks (checkpoints) are used for synchronizing qemu threads
+that perform operations with virtual hardware. These operations may change
+system's state (e.g., change some register or generate interrupt) and
+therefore should execute synchronously with CPU thread.
+
+Every event in the log includes 1-byte event id and optional arguments.
+When argument is an array, it is stored as 4-byte array length
+and corresponding number of bytes with data.
+Here is the list of events that are written into the log:
+
+ - EVENT_INSTRUCTION. Instructions executed since last event.
+   Argument: 4-byte number of executed instructions.
+ - EVENT_INTERRUPT. Used to synchronize interrupt processing.
+ - EVENT_EXCEPTION. Used to synchronize exception handling.
+ - EVENT_ASYNC. This is a group of events. They are always processed
+   together with checkpoints. When such an event is generated, it is
+   stored in the queue and processed only when checkpoint occurs.
+   Every such event is followed by 1-byte checkpoint id and 1-byte
+   async event id from the following list:
+ - REPLAY_ASYNC_EVENT_BH. Bottom-half callback. This event synchronizes
+   callbacks that affect virtual machine state, but normally called
+   asyncronously.
+   Argument: 8-byte operation id.
+ - REPLAY_ASYNC_EVENT_INPUT. Input device event. Contains
+   parameters of keyboard and mouse input operations
+   (key press/release, mouse pointer movement).
+   Arguments: 9-16 bytes depending of input event.
+ - REPLAY_ASYNC_EVENT_INPUT_SYNC. Internal input synchronization event.
+ - REPLAY_ASYNC_EVENT_CHAR_READ. Character (e.g., serial port) device input
+   initiated by the sender.
+   Arguments: 1-byte character device id.
+  Array with bytes were read.
+ - REPLAY_ASYNC_EVENT_BLOCK. Block device operation. Used to synchronize
+   operations with disk and flash drives with CPU.
+   Argument: 8-byte operation id.
+ - REPLAY_ASYNC_EVENT_NET. Incoming network packet.
+   Arguments: 1-byte network adapter id.
+  4-byte packet flags.
+  Array with packet bytes.
+ - EVENT_SHUTDOWN. Occurs when user sends shutdown event to qemu,
+   e.g., by closing the window.
+ - EVENT_CHAR_WRITE. Used to synchronize character output operations.
+   Arguments: 4-byte output function return value.
+  4-byte offset in the output array.
+ - EVENT_CHAR_READ_ALL. Used to synchronize character input operations,
+   initiated by qemu.
+   Argument: Array with bytes that were read.
+ - EVENT_CHAR_READ_ALL_ERROR. Unsuccessful character input operation,
+   initiated by qemu.
+   Argument: 4-byte error code.
+ - EVENT_CLOCK + clock_id. Group of events for host clock read operations.
+   Argument: 8-byte clock value.
+ - EVENT_CHECKPOINT + checkpoint_id. Checkpoint for synchronization of
+   CPU, internal threads, and asynchronous input events. May be followed
+   by one or more EVENT_ASYNC events.
+ - EVENT_END. Last event in the log.




[Qemu-devel] [RFC PATCH v5 10/24] target/arm/arm-powertctl: drop BQL assertions

2018-01-23 Thread Pavel Dovgalyuk
From: Alex Bennée 

The powerctl code is run in the context of the vCPU changing power
state. It does not need the BQL to protect its changes.

Signed-off-by: Alex Bennée 
---
 target/arm/arm-powerctl.c |8 
 1 file changed, 8 deletions(-)

diff --git a/target/arm/arm-powerctl.c b/target/arm/arm-powerctl.c
index 25207cb..9661a59 100644
--- a/target/arm/arm-powerctl.c
+++ b/target/arm/arm-powerctl.c
@@ -124,7 +124,6 @@ static void arm_set_cpu_on_async_work(CPUState 
*target_cpu_state,
 g_free(info);
 
 /* Finally set the power status */
-assert(qemu_mutex_iothread_locked());
 target_cpu->power_state = PSCI_ON;
 }
 
@@ -135,8 +134,6 @@ int arm_set_cpu_on(uint64_t cpuid, uint64_t entry, uint64_t 
context_id,
 ARMCPU *target_cpu;
 struct CpuOnInfo *info;
 
-assert(qemu_mutex_iothread_locked());
-
 DPRINTF("cpu %" PRId64 " (EL %d, %s) @ 0x%" PRIx64 " with R0 = 0x%" PRIx64
 "\n", cpuid, target_el, target_aa64 ? "aarch64" : "aarch32", entry,
 context_id);
@@ -227,7 +224,6 @@ static void arm_set_cpu_off_async_work(CPUState 
*target_cpu_state,
 {
 ARMCPU *target_cpu = ARM_CPU(target_cpu_state);
 
-assert(qemu_mutex_iothread_locked());
 target_cpu->power_state = PSCI_OFF;
 target_cpu_state->halted = 1;
 target_cpu_state->exception_index = EXCP_HLT;
@@ -238,8 +234,6 @@ int arm_set_cpu_off(uint64_t cpuid)
 CPUState *target_cpu_state;
 ARMCPU *target_cpu;
 
-assert(qemu_mutex_iothread_locked());
-
 DPRINTF("cpu %" PRId64 "\n", cpuid);
 
 /* change to the cpu we are powering up */
@@ -274,8 +268,6 @@ int arm_reset_cpu(uint64_t cpuid)
 CPUState *target_cpu_state;
 ARMCPU *target_cpu;
 
-assert(qemu_mutex_iothread_locked());
-
 DPRINTF("cpu %" PRId64 "\n", cpuid);
 
 /* change to the cpu we are resetting */




[Qemu-devel] [RFC PATCH v5 07/24] replay: fix save/load vm for non-empty queue

2018-01-23 Thread Pavel Dovgalyuk
This patch does not allows saving/loading vmstate when
replay events queue is not empty. There is no reliable
way to save events queue, because it describes internal
coroutine state. Therefore saving and loading operations
should be deferred to another record/replay step.

Signed-off-by: Pavel Dovgalyuk 

--

v2: fixed error_report calls
---
 include/sysemu/replay.h  |3 +++
 migration/savevm.c   |   13 +
 replay/replay-snapshot.c |6 ++
 3 files changed, 22 insertions(+)

diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index fa14d0e..b86d6bb 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -165,5 +165,8 @@ void replay_audio_in(int *recorded, void *samples, int 
*wpos, int size);
 /*! Called at the start of execution.
 Loads or saves initial vmstate depending on execution mode. */
 void replay_vmstate_init(void);
+/*! Called to ensure that replay state is consistent and VM snapshot
+can be created */
+bool replay_can_snapshot(void);
 
 #endif
diff --git a/migration/savevm.c b/migration/savevm.c
index b7908f6..99756e3 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -52,6 +52,7 @@
 #include "qemu/cutils.h"
 #include "io/channel-buffer.h"
 #include "io/channel-file.h"
+#include "sysemu/replay.h"
 
 #ifndef ETH_P_RARP
 #define ETH_P_RARP 0x8035
@@ -2141,6 +2142,12 @@ int save_snapshot(const char *name, Error **errp)
 struct tm tm;
 AioContext *aio_context;
 
+if (!replay_can_snapshot()) {
+error_report("Record/replay does not allow making snapshot "
+ "right now. Try once more later.");
+return ret;
+}
+
 if (!bdrv_all_can_snapshot(&bs)) {
 error_setg(errp, "Device '%s' is writable but does not support "
"snapshots", bdrv_get_device_name(bs));
@@ -2331,6 +2338,12 @@ int load_snapshot(const char *name, Error **errp)
 AioContext *aio_context;
 MigrationIncomingState *mis = migration_incoming_get_current();
 
+if (!replay_can_snapshot()) {
+error_report("Record/replay does not allow loading snapshot "
+ "right now. Try once more later.");
+return -EINVAL;
+}
+
 if (!bdrv_all_can_snapshot(&bs)) {
 error_setg(errp,
"Device '%s' is writable but does not support snapshots",
diff --git a/replay/replay-snapshot.c b/replay/replay-snapshot.c
index b2e1076..7075986 100644
--- a/replay/replay-snapshot.c
+++ b/replay/replay-snapshot.c
@@ -83,3 +83,9 @@ void replay_vmstate_init(void)
 }
 }
 }
+
+bool replay_can_snapshot(void)
+{
+return replay_mode == REPLAY_MODE_NONE
+|| !replay_has_events();
+}




[Qemu-devel] [RFC PATCH v5 04/24] replay: disable default snapshot for record/replay

2018-01-23 Thread Pavel Dovgalyuk
From: Pavel Dovgalyuk 

This patch disables setting '-snapshot' option on by default
in record/replay mode. This is needed for creating vmstates in record
and replay modes.

Signed-off-by: Pavel Dovgalyuk 
---
 vl.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/vl.c b/vl.c
index d147bfb..1d5ea70 100644
--- a/vl.c
+++ b/vl.c
@@ -3251,7 +3251,13 @@ int main(int argc, char **argv, char **envp)
 drive_add(IF_PFLASH, -1, optarg, PFLASH_OPTS);
 break;
 case QEMU_OPTION_snapshot:
-snapshot = 1;
+{
+Error *blocker = NULL;
+snapshot = 1;
+error_setg(&blocker, QERR_REPLAY_NOT_SUPPORTED,
+   "-snapshot");
+replay_add_blocker(blocker);
+}
 break;
 case QEMU_OPTION_numa:
 opts = qemu_opts_parse_noisily(qemu_find_opts("numa"),




[Qemu-devel] [RFC PATCH v5 05/24] replay: fix processing async events

2018-01-23 Thread Pavel Dovgalyuk
Asynchronous events saved at checkpoints may invoke
callbacks when processed. These callbacks may also generate/read
new events (e.g. clock reads). Therefore event processing flag must be
reset before callback invocation.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Paolo Bonzini 
---
 replay/replay-events.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/replay/replay-events.c b/replay/replay-events.c
index 94a6dcc..768b505 100644
--- a/replay/replay-events.c
+++ b/replay/replay-events.c
@@ -295,13 +295,13 @@ void replay_read_events(int checkpoint)
 if (!event) {
 break;
 }
+replay_finish_event();
+read_event_kind = -1;
 replay_mutex_unlock();
 replay_run_event(event);
 replay_mutex_lock();
 
 g_free(event);
-replay_finish_event();
-read_event_kind = -1;
 }
 }
 




[Qemu-devel] [RFC PATCH v5 03/24] blkreplay: create temporary overlay for underlaying devices

2018-01-23 Thread Pavel Dovgalyuk
From: Pavel Dovgalyuk 

This patch allows using '-snapshot' behavior in record/replay mode.
blkreplay layer creates temporary overlays on top of underlaying
disk images. It is needed, because creating an overlay over blkreplay
breaks the determinism.
This patch creates similar temporary overlay (when it is needed)
under the blkreplay driver. Therefore all block operations are controlled
by blkreplay.

Signed-off-by: Pavel Dovgalyuk 
---
 block/blkreplay.c |   65 +
 stubs/replay.c|1 +
 vl.c  |2 +-
 3 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/block/blkreplay.c b/block/blkreplay.c
index 4c58bd2..2bef4d6 100755
--- a/block/blkreplay.c
+++ b/block/blkreplay.c
@@ -14,12 +14,69 @@
 #include "block/block_int.h"
 #include "sysemu/replay.h"
 #include "qapi/error.h"
+#include "qapi/qmp/qstring.h"
 
 typedef struct Request {
 Coroutine *co;
 QEMUBH *bh;
 } Request;
 
+static BlockDriverState *blkreplay_append_snapshot(BlockDriverState *bs,
+   Error **errp)
+{
+int ret;
+BlockDriverState *bs_snapshot;
+int64_t total_size;
+QemuOpts *opts = NULL;
+char tmp_filename[PATH_MAX + 1];
+QDict *snapshot_options = qdict_new();
+
+/* Prepare options QDict for the overlay file */
+qdict_put(snapshot_options, "file.driver", qstring_from_str("file"));
+qdict_put(snapshot_options, "driver", qstring_from_str("qcow2"));
+
+/* Create temporary file */
+ret = get_tmp_filename(tmp_filename, PATH_MAX + 1);
+if (ret < 0) {
+error_setg_errno(errp, -ret, "Could not get temporary filename");
+goto out;
+}
+qdict_put(snapshot_options, "file.filename",
+  qstring_from_str(tmp_filename));
+
+/* Get the required size from the image */
+total_size = bdrv_getlength(bs);
+if (total_size < 0) {
+error_setg_errno(errp, -total_size, "Could not get image size");
+goto out;
+}
+
+opts = qemu_opts_create(bdrv_qcow2.create_opts, NULL, 0, &error_abort);
+qemu_opt_set_number(opts, BLOCK_OPT_SIZE, total_size, &error_abort);
+ret = bdrv_create(&bdrv_qcow2, tmp_filename, opts, errp);
+qemu_opts_del(opts);
+if (ret < 0) {
+error_prepend(errp, "Could not create temporary overlay '%s': ",
+  tmp_filename);
+goto out;
+}
+
+bs_snapshot = bdrv_open(NULL, NULL, snapshot_options,
+BDRV_O_RDWR | BDRV_O_TEMPORARY, errp);
+snapshot_options = NULL;
+if (!bs_snapshot) {
+goto out;
+}
+
+bdrv_append(bs_snapshot, bs, errp);
+
+return bs_snapshot;
+
+out:
+QDECREF(snapshot_options);
+return NULL;
+}
+
 static int blkreplay_open(BlockDriverState *bs, QDict *options, int flags,
   Error **errp)
 {
@@ -35,6 +92,14 @@ static int blkreplay_open(BlockDriverState *bs, QDict 
*options, int flags,
 goto fail;
 }
 
+/* Add temporary snapshot to preserve the image */
+if (!replay_snapshot
+&& !blkreplay_append_snapshot(bs->file->bs, &local_err)) {
+ret = -EINVAL;
+error_propagate(errp, local_err);
+goto fail;
+}
+
 ret = 0;
 fail:
 return ret;
diff --git a/stubs/replay.c b/stubs/replay.c
index 9c8aa48..9991ee5 100644
--- a/stubs/replay.c
+++ b/stubs/replay.c
@@ -3,6 +3,7 @@
 #include "sysemu/sysemu.h"
 
 ReplayMode replay_mode;
+char *replay_snapshot;
 
 int64_t replay_save_clock(unsigned int kind, int64_t clock)
 {
diff --git a/vl.c b/vl.c
index e725ecb..d147bfb 100644
--- a/vl.c
+++ b/vl.c
@@ -4548,7 +4548,7 @@ int main(int argc, char **argv, char **envp)
 qapi_free_BlockdevOptions(bdo->bdo);
 g_free(bdo);
 }
-if (snapshot || replay_mode != REPLAY_MODE_NONE) {
+if (snapshot) {
 qemu_opts_foreach(qemu_find_opts("drive"), drive_enable_snapshot,
   NULL, NULL);
 }




[Qemu-devel] [RFC PATCH v5 06/24] replay: fixed replay_enable_events

2018-01-23 Thread Pavel Dovgalyuk
This patch fixes assignment to internal events_enabled variable.
Now it is set only in record/replay mode. This affects the behavior
of the external functions that check this flag.

Signed-off-by: Pavel Dovgalyuk 
Acked-by: Paolo Bonzini 
---
 replay/replay-events.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/replay/replay-events.c b/replay/replay-events.c
index 768b505..e858254 100644
--- a/replay/replay-events.c
+++ b/replay/replay-events.c
@@ -67,7 +67,9 @@ static void replay_run_event(Event *event)
 
 void replay_enable_events(void)
 {
-events_enabled = true;
+if (replay_mode != REPLAY_MODE_NONE) {
+events_enabled = true;
+}
 }
 
 bool replay_has_events(void)
@@ -141,7 +143,7 @@ void replay_add_event(ReplayAsyncEventKind event_kind,
 
 void replay_bh_schedule_event(QEMUBH *bh)
 {
-if (replay_mode != REPLAY_MODE_NONE && events_enabled) {
+if (events_enabled) {
 uint64_t id = replay_get_current_step();
 replay_add_event(REPLAY_ASYNC_EVENT_BH, bh, NULL, id);
 } else {
@@ -161,7 +163,7 @@ void replay_add_input_sync_event(void)
 
 void replay_block_event(QEMUBH *bh, uint64_t id)
 {
-if (replay_mode != REPLAY_MODE_NONE && events_enabled) {
+if (events_enabled) {
 replay_add_event(REPLAY_ASYNC_EVENT_BLOCK, bh, NULL, id);
 } else {
 qemu_bh_schedule(bh);




[Qemu-devel] [RFC PATCH v5 01/24] cpu-exec: fix exception_index handling

2018-01-23 Thread Pavel Dovgalyuk
Function cpu_handle_interrupt calls cc->cpu_exec_interrupt to process
pending hardware interrupts. Under the hood cpu_exec_interrupt uses
cpu->exception_index to pass information to the internal function which
is usually common for exception and interrupt processing.
But this value is not reset after return and may be processed again
by cpu_handle_exception. This does not happen due to overwriting
the exception_index at the end of cpu_handle_interrupt.
But this branch may also overwrite the valid exception_index in some cases.
Therefore this patch:
 1. resets exception_index just after the call to cpu_exec_interrupt
 2. prevents overwriting the meaningful value of exception_index

Signed-off-by: Pavel Dovgalyuk 
Signed-off-by: Paolo Bonzini 
---
 accel/tcg/cpu-exec.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index 280200f..9cc6972 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -585,6 +585,7 @@ static inline bool cpu_handle_interrupt(CPUState *cpu,
 else {
 if (cc->cpu_exec_interrupt(cpu, interrupt_request)) {
 replay_interrupt();
+cpu->exception_index = -1;
 *last_tb = NULL;
 }
 /* The target hook may have updated the 'cpu->interrupt_request';
@@ -606,7 +607,9 @@ static inline bool cpu_handle_interrupt(CPUState *cpu,
 if (unlikely(atomic_read(&cpu->exit_request)
 || (use_icount && cpu->icount_decr.u16.low + cpu->icount_extra == 0))) 
{
 atomic_set(&cpu->exit_request, 0);
-cpu->exception_index = EXCP_INTERRUPT;
+if (cpu->exception_index == -1) {
+cpu->exception_index = EXCP_INTERRUPT;
+}
 return true;
 }
 




[Qemu-devel] [RFC PATCH v5 02/24] block: implement bdrv_snapshot_goto for blkreplay

2018-01-23 Thread Pavel Dovgalyuk
From: Pavel Dovgalyuk 

This patch enables making snapshots with blkreplay used in
block devices.
This function is required to make bdrv_snapshot_goto without
calling .bdrv_open which is not implemented.

Signed-off-by: Pavel Dovgalyuk 
---
 block/blkreplay.c |8 
 1 file changed, 8 insertions(+)

diff --git a/block/blkreplay.c b/block/blkreplay.c
index 61e44a1..4c58bd2 100755
--- a/block/blkreplay.c
+++ b/block/blkreplay.c
@@ -127,6 +127,12 @@ static int coroutine_fn 
blkreplay_co_flush(BlockDriverState *bs)
 return ret;
 }
 
+static int blkreplay_snapshot_goto(BlockDriverState *bs,
+   const char *snapshot_id)
+{
+return bdrv_snapshot_goto(bs->file->bs, snapshot_id, NULL);
+}
+
 static BlockDriver bdrv_blkreplay = {
 .format_name= "blkreplay",
 .protocol_name  = "blkreplay",
@@ -143,6 +149,8 @@ static BlockDriver bdrv_blkreplay = {
 .bdrv_co_pwrite_zeroes  = blkreplay_co_pwrite_zeroes,
 .bdrv_co_pdiscard   = blkreplay_co_pdiscard,
 .bdrv_co_flush  = blkreplay_co_flush,
+
+.bdrv_snapshot_goto = blkreplay_snapshot_goto,
 };
 
 static void bdrv_blkreplay_init(void)




[Qemu-devel] [RFC PATCH v5 00/24] replay additions

2018-01-23 Thread Pavel Dovgalyuk
Accidentally sent draft version of patches to the mailing list.
Please consider this one as the correct one.

This set of patches includex fixes from Alex Bennée for fixing
BQL and replay locks after inventing the MTTCG. It also includes some
additional replay patches that makes this set of fixes working.
It is also fixes some vmstate creation (and loading) issues
in record/replay modes:
 - VM start/stop fixes in replay mode
 - overlay creation for blkreplay filter
 - fixes for vmstate save/load in record/replay mode
 - fixes for host clock vmstate

There is also a set of helper scripts written by Alex Bennée
for debugging the record/replay code.

v5 changes:
 - removed patch for narrowing BQL-protected code
 - disabled bdrv_(drain/flush)_all for record/replay mode

v4 changes:
 - removed upstreamed patches
 - added patch for saving async queue state in replay
 - minor fixes

v3 changes:
 - removed upstreamed patches
 - fixed bug with recursive checkpoints
 - fixed bug with icount warp checkpoint

v2 changes:
 - updated lock/unlock logic (as suggested by Paolo Bonzini)
 - updated cpu execution loop to avoid races in setting/resetting exit request 
(as suggested by Paolo Bonzini)
 - minor changes

---

Alex Bennée (7):
  target/arm/arm-powertctl: drop BQL assertions
  cpus: push BQL lock to qemu_*_wait_io_event
  replay/replay.c: bump REPLAY_VERSION again
  replay/replay-internal.c: track holding of replay_lock
  replay: make locking visible outside replay code
  replay: push replay_mutex_lock up the call tree
  scripts/replay-dump.py: replay log dumper

Pavel Dovgalyuk (17):
  cpu-exec: fix exception_index handling
  block: implement bdrv_snapshot_goto for blkreplay
  blkreplay: create temporary overlay for underlaying devices
  replay: disable default snapshot for record/replay
  replay: fix processing async events
  replay: fixed replay_enable_events
  replay: fix save/load vm for non-empty queue
  replay: added replay log format description
  replay: save prior value of the host clock
  hax: remove BQL lock/unlock
  kvm: remove BQL lock/unlock
  replay: don't destroy mutex at exit
  replay: check return values of fwrite
  replay: avoid recursive call of checkpoints
  replay: don't process async events when warping the clock
  replay: save vmstate of the asynchronous events
  replay: don't drain/flush bdrv queue while RR is working


 accel/kvm/kvm-all.c   |3 
 accel/tcg/cpu-exec.c  |5 +
 block/blkreplay.c |   73 +++
 block/io.c|   22 +++
 cpus.c|   47 +--
 docs/replay.txt   |   91 +
 include/qemu/timer.h  |   14 ++
 include/sysemu/replay.h   |   19 +++
 migration/savevm.c|   13 ++
 replay/replay-char.c  |   21 +--
 replay/replay-events.c|   73 +--
 replay/replay-internal.c  |   48 ++-
 replay/replay-internal.h  |   15 ++
 replay/replay-snapshot.c  |   12 ++
 replay/replay-time.c  |   10 +
 replay/replay.c   |   62 ++---
 scripts/replay-dump.py|  308 +
 stubs/replay.c|   16 ++
 target/arm/arm-powerctl.c |8 -
 target/i386/hax-all.c |2 
 util/main-loop.c  |   17 ++
 util/qemu-timer.c |   12 ++
 vl.c  |   12 +-
 23 files changed, 777 insertions(+), 126 deletions(-)
 create mode 100755 scripts/replay-dump.py

-- 
Pavel Dovgalyuk



Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

2018-01-23 Thread Christian Ehrhardt
On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell  wrote:
> On 18 January 2018 at 02:01, Eduardo Habkost  wrote:
>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
>>
>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into 
>> staging (2018-01-16 17:36:39 +)
>>
>> are available in the Git repository at:
>>
>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
>>
>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
>>
>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
>>
>> 
>> x86 queue, 2018-01-17
>>
>> Highlight: new CPU models that expose CPU features that guests
>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
>>
>
> Applied, thanks.
>
> -- PMM
>

Hi,
I was kind of clinging to [1] so far and had the expectation that all
those would be wrapped up in 2.11.1 once ready.
I see that the s390x changes are targeted to qemu-stable (well to
admit I suggested so referring the article above).
So I'd expected to see this series to show up on qemu-stable as well
but haven't seen it so far.

Therefore I wanted to ask if there was a change of plans in that
regard or if it needs just a few days more to see (part of) this
series on qemu-stable and on its way into 2.11.1?

[1]: https://www.qemu.org/2018/01/04/spectre/



[Qemu-devel] [PATCH v3 25/25] cpu: get rid of cpu_generic_init()

2018-01-23 Thread Igor Mammedov
There aren't any users of the helper left, remove it.

Signed-off-by: Igor Mammedov 
---
CC: Richard Henderson 
CC: "Emilio G. Cota" 
CC: Paolo Bonzini 
CC: Eduardo Habkost 
CC: "Alex Bennée" 
CC: "Philippe Mathieu-Daudé" 
---
 qom/cpu.c | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/qom/cpu.c b/qom/cpu.c
index aab8437..cf6880d 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -304,22 +304,9 @@ static ObjectClass *cpu_common_class_by_name(const char 
*cpu_model)
 static void cpu_common_parse_features(const char *typename, char *features,
   Error **errp)
 {
-char *featurestr; /* Single "key=value" string being parsed */
 char *val;
-static bool cpu_globals_initialized;
-
-/* TODO: all callers of ->parse_features() need to be changed to
- * call it only once, so we can remove this check (or change it
- * to assert(!cpu_globals_initialized).
- * Current callers of ->parse_features() are:
- * - cpu_generic_init()
- */
-if (cpu_globals_initialized) {
-return;
-}
-cpu_globals_initialized = true;
-
-featurestr = features ? strtok(features, ",") : NULL;
+/* Single "key=value" string being parsed */
+char *featurestr = features ? strtok(features, ",") : NULL;
 
 while (featurestr) {
 val = strchr(featurestr, '=');
-- 
2.7.4




[Qemu-devel] [PATCH v3 17/25] sparc: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

PS:
sparc cpu model names might have spaces, add quotes around
cpu model name when creating CLI so QEMU could find cpu.

Signed-off-by: Igor Mammedov 
---
CC: Mark Cave-Ayland 
CC: Artyom Tarasenko 
---
 target/sparc/cpu.h| 1 +
 tests/machine-none-test.c | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
index 9fde547..345b39a 100644
--- a/target/sparc/cpu.h
+++ b/target/sparc/cpu.h
@@ -660,6 +660,7 @@ int cpu_sparc_signal_handler(int host_signum, void *pinfo, 
void *puc);
 
 #define SPARC_CPU_TYPE_SUFFIX "-" TYPE_SPARC_CPU
 #define SPARC_CPU_TYPE_NAME(model) model SPARC_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_SPARC_CPU
 
 #define cpu_signal_handler cpu_sparc_signal_handler
 #define cpu_list sparc_cpu_list
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 134036a..0f80d7b 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -47,6 +47,8 @@ static struct arch2cpu cpus_map[] = {
 { "s390x", "qemu" },
 { "sh4", "sh7750r" },
 { "sh4eb", "sh7751r" },
+{ "sparc", "LEON2" },
+{ "sparc64", "Fujitsu Sparc64" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
@@ -72,7 +74,7 @@ static void test_machine_cpu_cli(void)
 " add it to cpus_map\n", arch);
 return; /* TODO: die here to force all targets have a test */
 }
-global_qtest = qtest_startf("-machine none -cpu %s", cpu_model);
+global_qtest = qtest_startf("-machine none -cpu '%s'", cpu_model);
 
 response = qmp("{ 'execute': 'quit' }");
 g_assert(qdict_haskey(response, "return"));
-- 
2.7.4




[Qemu-devel] [PATCH v3 18/25] tricore: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Bastian Koppelmann 
---
 target/tricore/cpu.h  | 1 +
 tests/machine-none-test.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/tricore/cpu.h b/target/tricore/cpu.h
index f41d2ce..a2ef632 100644
--- a/target/tricore/cpu.h
+++ b/target/tricore/cpu.h
@@ -415,6 +415,7 @@ static inline void cpu_get_tb_cpu_state(CPUTriCoreState 
*env, target_ulong *pc,
 
 #define TRICORE_CPU_TYPE_SUFFIX "-" TYPE_TRICORE_CPU
 #define TRICORE_CPU_TYPE_NAME(model) model TRICORE_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_TRICORE_CPU
 
 /* helpers.c */
 int cpu_tricore_handle_mmu_fault(CPUState *cpu, target_ulong address,
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 0f80d7b..0430b06 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -49,6 +49,7 @@ static struct arch2cpu cpus_map[] = {
 { "sh4eb", "sh7751r" },
 { "sparc", "LEON2" },
 { "sparc64", "Fujitsu Sparc64" },
+{ "tricore", "tc1796" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 24/25] cpu: get rid of unused cpu_init() defines

2018-01-23 Thread Igor Mammedov
cpu_init(cpu_model) were replaced by cpu_create(cpu_type) so
no users are left, remove it.

Signed-off-by: Igor Mammedov 
---
CC: Richard Henderson  (maintainer:Alpha)
CC: Peter Maydell 
CC: "Edgar E. Iglesias" 
CC: Eduardo Habkost 
CC: Michael Walle 
CC: Laurent Vivier 
CC: Aurelien Jarno 
CC: Yongbok Kim 
CC: Anthony Green 
CC: Chris Wulff 
CC: Marek Vasut 
CC: Stafford Horne 
CC: David Gibson 
CC: Alexander Graf 
CC: Mark Cave-Ayland 
CC: Artyom Tarasenko 
CC: Bastian Koppelmann 
CC: Guan Xuetao 
CC: Max Filippov 
CC: qemu-...@nongnu.org
CC: qemu-...@nongnu.org
CC: qemu-s3...@nongnu.org
---
 target/alpha/cpu.h  | 2 --
 target/arm/cpu.h| 2 --
 target/cris/cpu.h   | 2 --
 target/hppa/cpu.h   | 1 -
 target/i386/cpu.h   | 2 --
 target/lm32/cpu.h   | 2 --
 target/m68k/cpu.h   | 2 --
 target/microblaze/cpu.h | 1 -
 target/mips/cpu.h   | 2 --
 target/moxie/cpu.h  | 2 --
 target/nios2/cpu.h  | 1 -
 target/openrisc/cpu.h   | 2 --
 target/ppc/cpu.h| 2 --
 target/s390x/cpu.h  | 2 --
 target/sh4/cpu.h| 2 --
 target/sparc/cpu.h  | 4 
 target/tilegx/cpu.h | 1 -
 target/tricore/cpu.h| 2 --
 target/unicore32/cpu.h  | 2 --
 target/xtensa/cpu.h | 2 --
 20 files changed, 38 deletions(-)

diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
index 21ed5d6..b3bec21 100644
--- a/target/alpha/cpu.h
+++ b/target/alpha/cpu.h
@@ -468,8 +468,6 @@ enum {
 
 void alpha_translate_init(void);
 
-#define cpu_init(cpu_model) cpu_generic_init(TYPE_ALPHA_CPU, cpu_model)
-
 #define ALPHA_CPU_TYPE_SUFFIX "-" TYPE_ALPHA_CPU
 #define ALPHA_CPU_TYPE_NAME(model) model ALPHA_CPU_TYPE_SUFFIX
 #define CPU_RESOLVING_TYPE TYPE_ALPHA_CPU
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index f9fb141..b37d266 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -2167,8 +2167,6 @@ static inline bool arm_excp_unmasked(CPUState *cs, 
unsigned int excp_idx,
 return unmasked || pstate_unmasked;
 }
 
-#define cpu_init(cpu_model) cpu_generic_init(TYPE_ARM_CPU, cpu_model)
-
 #define ARM_CPU_TYPE_SUFFIX "-" TYPE_ARM_CPU
 #define ARM_CPU_TYPE_NAME(name) (name ARM_CPU_TYPE_SUFFIX)
 #define CPU_RESOLVING_TYPE TYPE_ARM_CPU
diff --git a/target/cris/cpu.h b/target/cris/cpu.h
index 1a27653..db80cb1 100644
--- a/target/cris/cpu.h
+++ b/target/cris/cpu.h
@@ -267,8 +267,6 @@ enum {
 #define TARGET_PHYS_ADDR_SPACE_BITS 32
 #define TARGET_VIRT_ADDR_SPACE_BITS 32
 
-#define cpu_init(cpu_model) cpu_generic_init(TYPE_CRIS_CPU, cpu_model)
-
 #define CRIS_CPU_TYPE_SUFFIX "-" TYPE_CRIS_CPU
 #define CRIS_CPU_TYPE_NAME(name) (name CRIS_CPU_TYPE_SUFFIX)
 #define CPU_RESOLVING_TYPE TYPE_CRIS_CPU
diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
index b92ae3f..628d7de 100644
--- a/target/hppa/cpu.h
+++ b/target/hppa/cpu.h
@@ -112,7 +112,6 @@ static inline int cpu_mmu_index(CPUHPPAState *env, bool 
ifetch)
 
 void hppa_translate_init(void);
 
-#define cpu_init(cpu_model) cpu_generic_init(TYPE_HPPA_CPU, cpu_model)
 #define CPU_RESOLVING_TYPE TYPE_HPPA_CPU
 
 void hppa_cpu_list(FILE *f, fprintf_function cpu_fprintf);
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 82c7381..1ed60b0 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1564,8 +1564,6 @@ uint64_t cpu_get_tsc(CPUX86State *env);
 
 #define PHYS_ADDR_MASK MAKE_64BIT_MASK(0, TCG_PHYS_ADDR_BITS)
 
-#define cpu_init(cpu_model) cpu_generic_init(TYPE_X86_CPU, cpu_model)
-
 #define X86_CPU_TYPE_SUFFIX "-" TYPE_X86_CPU
 #define X86_CPU_TYPE_NAME(name) (name X86_CPU_TYPE_SUFFIX)
 #define CPU_RESOLVING_TYPE TYPE_X86_CPU
diff --git a/target/lm32/cpu.h b/target/lm32/cpu.h
index 0656052..53939e5 100644
--- a/target/lm32/cpu.h
+++ b/target/lm32/cpu.h
@@ -255,8 +255,6 @@ void lm32_watchpoint_insert(CPULM32State *env, int index, 
target_ulong address,
 void lm32_watchpoint_remove(CPULM32State *env, int index);
 bool lm32_cpu_do_semihosting(CPUState *cs);
 
-#define cpu_init(cpu_model) cpu_generic_init(TYPE_LM32_CPU, cpu_model)
-
 #define LM32_CPU_TYPE_SUFFIX "-" TYPE_LM32_CPU
 #define LM32_CPU_TYPE_NAME(model) model LM32_CPU_TYPE_SUFFIX
 #define CPU_RESOLVING_TYPE TYPE_LM32_CPU
diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index 8a4299a..7d64804 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -401,8 +401,6 @@ void register_m68k_insns (CPUM68KState *env);
 #define TARGET_PHYS_ADDR_SPACE_BITS 32
 #define TARGET_VIRT_ADDR_SPACE_BITS 32
 
-#define cpu_init(cpu_model) cpu_generic_init(TYPE_M68K_CPU, cpu_model)
-
 #define M68K_CPU_TYPE_SUFFIX "-" TYPE_M68K_CPU
 #define M68K_CPU_TYPE_NAME(model) model M68K_CPU_TYPE_SUFFIX
 #define CPU_RESOLVING_TYPE TYPE_M68K_CPU
diff --git a/target/microblaze/cpu.h b/target/microblaze/cpu.h
index 492f9f7..a0ea421 100644
--- a/target/microblaze/cpu.h
+++ b/target/microblaze/cpu.h
@@ -343,7 +343,6 @@ int cpu_mb_signal_handler(int host_signum, void *pinfo,
 #define TARGET_PHYS_ADDR_SPACE_BITS 32
 #define TARGET_VIRT_ADDR_SPACE_BITS 32
 
-#define cpu_init(cpu_model) cpu_generic_init(TYPE_MICROBLAZ

[Qemu-devel] [PATCH v3 13/25] openrisc: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Stafford Horne 
---
 target/openrisc/cpu.h | 1 +
 tests/machine-none-test.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/openrisc/cpu.h b/target/openrisc/cpu.h
index cc22dc8..9b32ea4 100644
--- a/target/openrisc/cpu.h
+++ b/target/openrisc/cpu.h
@@ -394,6 +394,7 @@ int cpu_openrisc_get_phys_data(OpenRISCCPU *cpu,
 
 #define OPENRISC_CPU_TYPE_SUFFIX "-" TYPE_OPENRISC_CPU
 #define OPENRISC_CPU_TYPE_NAME(model) model OPENRISC_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_OPENRISC_CPU
 
 #include "exec/cpu-all.h"
 
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index c6ad495..160aa13 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -40,6 +40,7 @@ static struct arch2cpu cpus_map[] = {
 { "mips64el", "20Kc" },
 { "moxie", "MoxieLite" },
 { "nios2", "FIXME" },
+{ "or1k", "or1200" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 22/25] tilegx: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Eduardo Habkost 
---
 target/tilegx/cpu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/tilegx/cpu.h b/target/tilegx/cpu.h
index 71cea04..a73215e 100644
--- a/target/tilegx/cpu.h
+++ b/target/tilegx/cpu.h
@@ -165,6 +165,7 @@ void tilegx_tcg_init(void);
 int cpu_tilegx_signal_handler(int host_signum, void *pinfo, void *puc);
 
 #define cpu_init(cpu_model) cpu_generic_init(TYPE_TILEGX_CPU, cpu_model)
+#define CPU_RESOLVING_TYPE TYPE_TILEGX_CPU
 
 #define cpu_signal_handler cpu_tilegx_signal_handler
 
-- 
2.7.4




[Qemu-devel] [PATCH v3 23/25] Use cpu_create(type) instead of cpu_init(cpu_model)

2018-01-23 Thread Igor Mammedov
With all targets defining CPU_RESOLVING_TYPE, refactor
cpu_parse_cpu_model(type, cpu_model) to parse_cpu_model(cpu_model)
so that callers won't have to know internal resolving cpu
type. Place it in exec.c so it could be called from both
target independed vl.c and *-user/main.c.

That allows us to stop abusing cpu type from
  MachineClass::default_cpu_type
as resolver class in vl.c which were confusing part of
cpu_parse_cpu_model().

Also with new parse_cpu_model(), the last users of cpu_init()
in null-machine.c and bsd/linux-user targets could be switched
to cpu_create() API and cpu_init() API will be removed by
follow up patch.

Signed-off-by: Igor Mammedov 
---
 include/qom/cpu.h  | 16 ++--
 bsd-user/main.c|  4 +++-
 exec.c | 23 +++
 hw/core/null-machine.c |  6 +++---
 linux-user/main.c  |  8 ++--
 qom/cpu.c  | 31 ---
 vl.c   | 10 +++---
 7 files changed, 40 insertions(+), 58 deletions(-)

diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 93bd546..0185589 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -661,8 +661,7 @@ ObjectClass *cpu_class_by_name(const char *typename, const 
char *cpu_model);
 CPUState *cpu_create(const char *typename);
 
 /**
- * cpu_parse_cpu_model:
- * @typename: The CPU base type or CPU type.
+ * parse_cpu_model:
  * @cpu_model: The model string including optional parameters.
  *
  * processes optional parameters and registers them as global properties
@@ -670,18 +669,7 @@ CPUState *cpu_create(const char *typename);
  * Returns: type of CPU to create or prints error and terminates process
  *  if an error occurred.
  */
-const char *cpu_parse_cpu_model(const char *typename, const char *cpu_model);
-
-/**
- * cpu_generic_init:
- * @typename: The CPU base type.
- * @cpu_model: The model string including optional parameters.
- *
- * Instantiates a CPU, processes optional parameters and realizes the CPU.
- *
- * Returns: A #CPUState or %NULL if an error occurred.
- */
-CPUState *cpu_generic_init(const char *typename, const char *cpu_model);
+const char *parse_cpu_model(const char *cpu_model);
 
 /**
  * cpu_has_work:
diff --git a/bsd-user/main.c b/bsd-user/main.c
index efef5ff..cbc683a 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -723,6 +723,7 @@ int main(int argc, char **argv)
 {
 const char *filename;
 const char *cpu_model;
+const char *cpu_type;
 const char *log_file = NULL;
 const char *log_mask = NULL;
 struct target_pt_regs regs1, *regs = ®s1;
@@ -900,7 +901,8 @@ int main(int argc, char **argv)
 tcg_exec_init(0);
 /* NOTE: we need to init the CPU at this stage to get
qemu_host_page_size */
-cpu = cpu_init(cpu_model);
+cpu_type = parse_cpu_model(cpu_model);
+cpu = create(cpu_type);
 env = cpu->env_ptr;
 #if defined(TARGET_SPARC) || defined(TARGET_PPC)
 cpu_reset(cpu);
diff --git a/exec.c b/exec.c
index 629a508..8aee230 100644
--- a/exec.c
+++ b/exec.c
@@ -817,6 +817,29 @@ void cpu_exec_realizefn(CPUState *cpu, Error **errp)
 #endif
 }
 
+const char *parse_cpu_model(const char *cpu_model)
+{
+ObjectClass *oc;
+CPUClass *cc;
+gchar **model_pieces;
+const char *cpu_type;
+
+model_pieces = g_strsplit(cpu_model, ",", 2);
+
+oc = cpu_class_by_name(CPU_RESOLVING_TYPE, model_pieces[0]);
+if (oc == NULL) {
+error_report("unable to find CPU model '%s'", model_pieces[0]);
+g_strfreev(model_pieces);
+exit(EXIT_FAILURE);
+}
+
+cpu_type = object_class_get_name(oc);
+cc = CPU_CLASS(oc);
+cc->parse_features(cpu_type, model_pieces[1], &error_fatal);
+g_strfreev(model_pieces);
+return cpu_type;
+}
+
 #if defined(CONFIG_USER_ONLY)
 static void breakpoint_invalidate(CPUState *cpu, target_ulong pc)
 {
diff --git a/hw/core/null-machine.c b/hw/core/null-machine.c
index 864832d..cde4d3e 100644
--- a/hw/core/null-machine.c
+++ b/hw/core/null-machine.c
@@ -24,9 +24,9 @@ static void machine_none_init(MachineState *mch)
 {
 CPUState *cpu = NULL;
 
-/* Initialize CPU (if a model has been specified) */
-if (mch->cpu_model) {
-cpu = cpu_init(mch->cpu_model);
+/* Initialize CPU (if user asked for it) */
+if (mch->cpu_type) {
+cpu = cpu_create(mch->cpu_type);
 if (!cpu) {
 error_report("Unable to initialize CPU");
 exit(1);
diff --git a/linux-user/main.c b/linux-user/main.c
index a35477e..0afb3f4 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -44,6 +44,7 @@ static const char *argv0;
 static int gdbstub_port;
 static envlist_t *envlist;
 static const char *cpu_model;
+static const char *cpu_type;
 unsigned long mmap_min_addr;
 unsigned long guest_base;
 int have_guest_base;
@@ -3847,7 +3848,7 @@ void init_task_state(TaskState *ts)
 CPUArchState *cpu_copy(CPUArchState *env)
 {
 CPUState *cpu = ENV_GET_CPU(env);
-CPUState *new_cpu = cpu

[Qemu-devel] [PATCH v3 20/25] xtensa: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Max Filippov 
---
 target/xtensa/cpu.h   | 1 +
 tests/machine-none-test.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
index d9404aa..23dbd45 100644
--- a/target/xtensa/cpu.h
+++ b/target/xtensa/cpu.h
@@ -500,6 +500,7 @@ void xtensa_cpu_do_unaligned_access(CPUState *cpu, vaddr 
addr,
 
 #define XTENSA_CPU_TYPE_SUFFIX "-" TYPE_XTENSA_CPU
 #define XTENSA_CPU_TYPE_NAME(model) model XTENSA_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_XTENSA_CPU
 
 #ifdef TARGET_WORDS_BIGENDIAN
 #define XTENSA_DEFAULT_CPU_MODEL "fsf"
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index a8a499e..a1e9980 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -51,6 +51,8 @@ static struct arch2cpu cpus_map[] = {
 { "sparc64", "Fujitsu Sparc64" },
 { "tricore", "tc1796" },
 { "unicore32", "UniCore-II" },
+{ "xtensa", "dc233c" },
+{ "xtensaeb", "fsf" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 14/25] ppc: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Laurent Vivier 
CC: David Gibson 
CC: Alexander Graf 
CC: qemu-...@nongnu.org
---
 target/ppc/cpu.h  | 1 +
 tests/machine-none-test.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index 603a38c..d5f2f3d 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1380,6 +1380,7 @@ int ppc_dcr_write (ppc_dcr_t *dcr_env, int dcrn, uint32_t 
val);
 
 #define POWERPC_CPU_TYPE_SUFFIX "-" TYPE_POWERPC_CPU
 #define POWERPC_CPU_TYPE_NAME(model) model POWERPC_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_POWERPC_CPU
 
 #define cpu_signal_handler cpu_ppc_signal_handler
 #define cpu_list ppc_cpu_list
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 160aa13..052b8c0 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -41,6 +41,9 @@ static struct arch2cpu cpus_map[] = {
 { "moxie", "MoxieLite" },
 { "nios2", "FIXME" },
 { "or1k", "or1200" },
+{ "ppc", "604" },
+{ "ppc64", "power8e_v2.1" },
+{ "ppcemb", "440epb" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 21/25] hppa: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Richard Henderson 
---
 target/hppa/cpu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
index 8d14077..b92ae3f 100644
--- a/target/hppa/cpu.h
+++ b/target/hppa/cpu.h
@@ -113,6 +113,7 @@ static inline int cpu_mmu_index(CPUHPPAState *env, bool 
ifetch)
 void hppa_translate_init(void);
 
 #define cpu_init(cpu_model) cpu_generic_init(TYPE_HPPA_CPU, cpu_model)
+#define CPU_RESOLVING_TYPE TYPE_HPPA_CPU
 
 void hppa_cpu_list(FILE *f, fprintf_function cpu_fprintf);
 
-- 
2.7.4




[Qemu-devel] [PATCH v3 10/25] mips: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Aurelien Jarno 
CC: Yongbok Kim 
---
 target/mips/cpu.h | 1 +
 tests/machine-none-test.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/target/mips/cpu.h b/target/mips/cpu.h
index 7f8ba5f..0fcbfb3 100644
--- a/target/mips/cpu.h
+++ b/target/mips/cpu.h
@@ -743,6 +743,7 @@ int cpu_mips_signal_handler(int host_signum, void *pinfo, 
void *puc);
 
 #define MIPS_CPU_TYPE_SUFFIX "-" TYPE_MIPS_CPU
 #define MIPS_CPU_TYPE_NAME(model) model MIPS_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_MIPS_CPU
 
 bool cpu_supports_cps_smp(const char *cpu_type);
 bool cpu_supports_isa(const char *cpu_type, unsigned int isa);
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 984def6..9bc6a06 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -34,6 +34,10 @@ static struct arch2cpu cpus_map[] = {
 { "m68k", "m5206" },
 /* FIXME: { "microblaze", "any" }, doesn't work with -M none -cpu any */
 /* FIXME: { "microblazeel", "any" }, doesn't work with -M none -cpu any */
+{ "mips", "4Kc" },
+{ "mipsel", "4Kc" },
+{ "mips64", "20Kc" },
+{ "mips64el", "20Kc" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 15/25] s390x: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Richard Henderson 
CC: Alexander Graf 
CC: qemu-s3...@nongnu.org
---
 target/s390x/cpu.h| 1 +
 tests/machine-none-test.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index 1a8b6b9..b2121cb 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h
@@ -731,6 +731,7 @@ void s390_set_qemu_cpu_model(uint16_t type, uint8_t gen, 
uint8_t ec_ga,
 
 #define S390_CPU_TYPE_SUFFIX "-" TYPE_S390_CPU
 #define S390_CPU_TYPE_NAME(name) (name S390_CPU_TYPE_SUFFIX)
+#define CPU_RESOLVING_TYPE TYPE_S390_CPU
 
 /* you can call this signal handler from your SIGBUS and SIGSEGV
signal handlers to inform the virtual CPU of exceptions. non zero
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 052b8c0..b3a346d 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -44,6 +44,7 @@ static struct arch2cpu cpus_map[] = {
 { "ppc", "604" },
 { "ppc64", "power8e_v2.1" },
 { "ppcemb", "440epb" },
+{ "s390x", "qemu" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 12/25] nios2: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

TODO:
 make nios2_cpu_class_by_name() to do name check instead of
 accepting anything

Signed-off-by: Igor Mammedov 
---
CC: Chris Wulff 
CC: Marek Vasut 
---
 target/nios2/cpu.h| 1 +
 tests/machine-none-test.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/nios2/cpu.h b/target/nios2/cpu.h
index 88823a6..2234bff 100644
--- a/target/nios2/cpu.h
+++ b/target/nios2/cpu.h
@@ -232,6 +232,7 @@ void nios2_check_interrupts(CPUNios2State *env);
 #endif
 
 #define cpu_init(cpu_model) cpu_generic_init(TYPE_NIOS2_CPU, cpu_model)
+#define CPU_RESOLVING_TYPE TYPE_NIOS2_CPU
 
 #define cpu_gen_code cpu_nios2_gen_code
 #define cpu_signal_handler cpu_nios2_signal_handler
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index c15a857..c6ad495 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -39,6 +39,7 @@ static struct arch2cpu cpus_map[] = {
 { "mips64", "20Kc" },
 { "mips64el", "20Kc" },
 { "moxie", "MoxieLite" },
+{ "nios2", "FIXME" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 19/25] unicore32: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Laurent Vivier 
CC: Guan Xuetao 
---
 target/unicore32/cpu.h| 1 +
 tests/machine-none-test.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/unicore32/cpu.h b/target/unicore32/cpu.h
index 3dc6fbc..9644b07 100644
--- a/target/unicore32/cpu.h
+++ b/target/unicore32/cpu.h
@@ -169,6 +169,7 @@ static inline int cpu_mmu_index(CPUUniCore32State *env, 
bool ifetch)
 
 #define UNICORE32_CPU_TYPE_SUFFIX "-" TYPE_UNICORE32_CPU
 #define UNICORE32_CPU_TYPE_NAME(model) model UNICORE32_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_UNICORE32_CPU
 
 static inline void cpu_get_tb_cpu_state(CPUUniCore32State *env, target_ulong 
*pc,
 target_ulong *cs_base, uint32_t *flags)
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 0430b06..a8a499e 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -50,6 +50,7 @@ static struct arch2cpu cpus_map[] = {
 { "sparc", "LEON2" },
 { "sparc64", "Fujitsu Sparc64" },
 { "tricore", "tc1796" },
+{ "unicore32", "UniCore-II" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 08/25] m68k: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Laurent Vivier 
---
 target/m68k/cpu.h | 1 +
 tests/machine-none-test.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index 2985b03..8a4299a 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -405,6 +405,7 @@ void register_m68k_insns (CPUM68KState *env);
 
 #define M68K_CPU_TYPE_SUFFIX "-" TYPE_M68K_CPU
 #define M68K_CPU_TYPE_NAME(model) model M68K_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_M68K_CPU
 
 #define cpu_signal_handler cpu_m68k_signal_handler
 #define cpu_list m68k_cpu_list
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 1159290..c9445b6 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -31,6 +31,7 @@ static struct arch2cpu cpus_map[] = {
 { "alpha", "ev67" },
 { "cris", "crisv32" },
 { "lm32", "lm32-full" },
+{ "m68k", "m5206" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 06/25] cris: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: "Edgar E. Iglesias" 
---
 target/cris/cpu.h | 1 +
 tests/machine-none-test.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/cris/cpu.h b/target/cris/cpu.h
index b64fa35..1a27653 100644
--- a/target/cris/cpu.h
+++ b/target/cris/cpu.h
@@ -271,6 +271,7 @@ enum {
 
 #define CRIS_CPU_TYPE_SUFFIX "-" TYPE_CRIS_CPU
 #define CRIS_CPU_TYPE_NAME(name) (name CRIS_CPU_TYPE_SUFFIX)
+#define CPU_RESOLVING_TYPE TYPE_CRIS_CPU
 
 #define cpu_signal_handler cpu_cris_signal_handler
 
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 5d23ade..68f7a30 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -29,6 +29,7 @@ static struct arch2cpu cpus_map[] = {
 { "x86_64", "qemu64,apic-id=0" },
 { "i386", "qemu32,apic-id=0" },
 { "alpha", "ev67" },
+{ "cris", "crisv32" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 09/25] microblaze: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

PC:
 target cpu can't be instantiated with -M none -cpu
 Add FIXME note in test, so microblaze maintainers
 could fix it in future and add proper error checking
 in cpu_model resolver which accepts any junk now.

Signed-off-by: Igor Mammedov 
---
CC: "Edgar E. Iglesias" 
---
 target/microblaze/cpu.h   | 1 +
 tests/machine-none-test.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/target/microblaze/cpu.h b/target/microblaze/cpu.h
index 52b6b6a..492f9f7 100644
--- a/target/microblaze/cpu.h
+++ b/target/microblaze/cpu.h
@@ -344,6 +344,7 @@ int cpu_mb_signal_handler(int host_signum, void *pinfo,
 #define TARGET_VIRT_ADDR_SPACE_BITS 32
 
 #define cpu_init(cpu_model) cpu_generic_init(TYPE_MICROBLAZE_CPU, cpu_model)
+#define CPU_RESOLVING_TYPE TYPE_MICROBLAZE_CPU
 
 #define cpu_signal_handler cpu_mb_signal_handler
 
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index c9445b6..984def6 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -32,6 +32,8 @@ static struct arch2cpu cpus_map[] = {
 { "cris", "crisv32" },
 { "lm32", "lm32-full" },
 { "m68k", "m5206" },
+/* FIXME: { "microblaze", "any" }, doesn't work with -M none -cpu any */
+/* FIXME: { "microblazeel", "any" }, doesn't work with -M none -cpu any */
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 16/25] sh4: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Aurelien Jarno 
---
 target/sh4/cpu.h  | 1 +
 tests/machine-none-test.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h
index a2c26e0..709e0ca 100644
--- a/target/sh4/cpu.h
+++ b/target/sh4/cpu.h
@@ -278,6 +278,7 @@ void cpu_load_tlb(CPUSH4State * env);
 
 #define SUPERH_CPU_TYPE_SUFFIX "-" TYPE_SUPERH_CPU
 #define SUPERH_CPU_TYPE_NAME(model) model SUPERH_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_SUPERH_CPU
 
 #define cpu_signal_handler cpu_sh4_signal_handler
 #define cpu_list sh4_cpu_list
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index b3a346d..134036a 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -45,6 +45,8 @@ static struct arch2cpu cpus_map[] = {
 { "ppc64", "power8e_v2.1" },
 { "ppcemb", "440epb" },
 { "s390x", "qemu" },
+{ "sh4", "sh7750r" },
+{ "sh4eb", "sh7751r" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 01/25] nios2: 10m50_devboard: replace cpu_model with cpu_type

2018-01-23 Thread Igor Mammedov
use cpu_create() instead of being removed cpu_generic_init()

Signed-off-by: Igor Mammedov 
---
CC: Chris Wulff 
CC: Marek Vasut 
---
 hw/nios2/10m50_devboard.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/nios2/10m50_devboard.c b/hw/nios2/10m50_devboard.c
index e4007f6..42053b2 100644
--- a/hw/nios2/10m50_devboard.c
+++ b/hw/nios2/10m50_devboard.c
@@ -75,7 +75,7 @@ static void nios2_10m50_ghrd_init(MachineState *machine)
 phys_ram_alias);
 
 /* Create CPU -- FIXME */
-cpu = NIOS2_CPU(cpu_generic_init(TYPE_NIOS2_CPU, "nios2"));
+cpu = NIOS2_CPU(cpu_create(TYPE_NIOS2_CPU));
 
 /* Register: CPU interrupt controller (PIC) */
 cpu_irq = nios2_cpu_pic_init(cpu);
-- 
2.7.4




[Qemu-devel] [PATCH v3 04/25] x86: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Eduardo Habkost 
---
 target/i386/cpu.h | 1 +
 tests/machine-none-test.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 30cc562..82c7381 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1568,6 +1568,7 @@ uint64_t cpu_get_tsc(CPUX86State *env);
 
 #define X86_CPU_TYPE_SUFFIX "-" TYPE_X86_CPU
 #define X86_CPU_TYPE_NAME(name) (name X86_CPU_TYPE_SUFFIX)
+#define CPU_RESOLVING_TYPE TYPE_X86_CPU
 
 #ifdef TARGET_X86_64
 #define TARGET_DEFAULT_CPU_TYPE X86_CPU_TYPE_NAME("qemu64")
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 1b213ff..4b704fb 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -26,6 +26,8 @@ static struct arch2cpu cpus_map[] = {
 /* tested targets list */
 { "arm", "cortex-a15" },
 { "aarch64", "cortex-a15" },
+{ "x86_64", "qemu64,apic-id=0" },
+{ "i386", "qemu32,apic-id=0" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 11/25] moxie: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Anthony Green 
---
 target/moxie/cpu.h| 1 +
 tests/machine-none-test.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/moxie/cpu.h b/target/moxie/cpu.h
index d37e6a5..3f94a5a 100644
--- a/target/moxie/cpu.h
+++ b/target/moxie/cpu.h
@@ -124,6 +124,7 @@ int cpu_moxie_signal_handler(int host_signum, void *pinfo,
 
 #define MOXIE_CPU_TYPE_SUFFIX "-" TYPE_MOXIE_CPU
 #define MOXIE_CPU_TYPE_NAME(model) model MOXIE_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_MOXIE_CPU
 
 #define cpu_signal_handler cpu_moxie_signal_handler
 
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 9bc6a06..c15a857 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -38,6 +38,7 @@ static struct arch2cpu cpus_map[] = {
 { "mipsel", "4Kc" },
 { "mips64", "20Kc" },
 { "mips64el", "20Kc" },
+{ "moxie", "MoxieLite" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 00/25] generalize parsing of cpu_model (part 4)

2018-01-23 Thread Igor Mammedov

v3:
  - use qtest_startf() instead of qtest_start()
  - rename tests/machine-none.c to tests/machine-none-test.c
  - introduce first CPU_RESOLVING_TYPE for all targets and
only then use it parse_cpu_model() 
  - stop abusing  mc->default_cpu_type as resolving cpu type,
move cpu_parse_cpu_model() in to exec.c and embed in
CPU_RESOLVING_TYPE, so that callers won't have to know
about unnecessary detail

v2:
  - implemented new approach only for x86/ARM (will be done for all targets
if approach seems acceptable)
  - add test case for '-M none -cpu FOO' case
  - redefine TARGET_DEFAULT_CPU_TYPE into CPU_RESOLVING_TYPE
  - scrape off default cpu_model refactoring, so it would cause
less conflicts with Laurent's series where he tries to rework
defaults to use ELF hints of executed program

Series is finishing work on generalizing cpu_model parsing
and limiting parts that deal with inconsistent cpu_model
naming to "-cpu" CLI option in vl.c, bsd|linux-user/main.c
CLI and default cpu_model processing and FOO_cpu_class_by_name()
callbacks.

It introduces CPU_RESOLVING_TYPE which must be defined
by each target and is used by helper parse_cpu_model()
(former cpu_parse_cpu_model()) to get access to target
specific FOO_cpu_class_by_name() callback.

git tree for testing:
   https://github.com/imammedo/qemu.git cpu_init_removal_v3

CC: Laurent Vivier 
CC: Eduardo Habkost 
CC: qemu-s3...@nongnu.org
CC: qemu-...@nongnu.org
CC: qemu-...@nongnu.org

Igor Mammedov (25):
  nios2: 10m50_devboard: replace cpu_model with cpu_type
  tests: add machine 'none' with -cpu test
  arm: cpu: add CPU_RESOLVING_TYPE macro
  x86: cpu: add CPU_RESOLVING_TYPE macro
  alpha: cpu: add CPU_RESOLVING_TYPE macro
  cris: cpu: add CPU_RESOLVING_TYPE macro
  lm32: cpu: add CPU_RESOLVING_TYPE macro
  m68k: cpu: add CPU_RESOLVING_TYPE macro
  microblaze: cpu: add CPU_RESOLVING_TYPE macro
  mips: cpu: add CPU_RESOLVING_TYPE macro
  moxie: cpu: add CPU_RESOLVING_TYPE macro
  nios2: cpu: add CPU_RESOLVING_TYPE macro
  openrisc: cpu: add CPU_RESOLVING_TYPE macro
  ppc: cpu: add CPU_RESOLVING_TYPE macro
  s390x: cpu: add CPU_RESOLVING_TYPE macro
  sh4: cpu: add CPU_RESOLVING_TYPE macro
  sparc: cpu: add CPU_RESOLVING_TYPE macro
  tricore: cpu: add CPU_RESOLVING_TYPE macro
  unicore32: cpu: add CPU_RESOLVING_TYPE macro
  xtensa: cpu: add CPU_RESOLVING_TYPE macro
  hppa: cpu: add CPU_RESOLVING_TYPE macro
  tilegx: cpu: add CPU_RESOLVING_TYPE macro
  Use cpu_create(type) instead of cpu_init(cpu_model)
  cpu: get rid of unused cpu_init() defines
  cpu: get rid of cpu_generic_init()

 include/qom/cpu.h | 16 +---
 target/alpha/cpu.h|  3 +-
 target/arm/cpu.h  |  3 +-
 target/cris/cpu.h |  3 +-
 target/hppa/cpu.h |  2 +-
 target/i386/cpu.h |  3 +-
 target/lm32/cpu.h |  3 +-
 target/m68k/cpu.h |  3 +-
 target/microblaze/cpu.h   |  2 +-
 target/mips/cpu.h |  3 +-
 target/moxie/cpu.h|  3 +-
 target/nios2/cpu.h|  2 +-
 target/openrisc/cpu.h |  3 +-
 target/ppc/cpu.h  |  3 +-
 target/s390x/cpu.h|  3 +-
 target/sh4/cpu.h  |  3 +-
 target/sparc/cpu.h|  5 +--
 target/tilegx/cpu.h   |  2 +-
 target/tricore/cpu.h  |  3 +-
 target/unicore32/cpu.h|  3 +-
 target/xtensa/cpu.h   |  3 +-
 bsd-user/main.c   |  4 +-
 exec.c| 23 +++
 hw/core/null-machine.c|  6 +--
 hw/nios2/10m50_devboard.c |  2 +-
 linux-user/main.c | 10 +++--
 qom/cpu.c | 48 +--
 tests/Makefile.include|  2 +
 tests/machine-none-test.c | 97 +++
 vl.c  | 10 ++---
 30 files changed, 162 insertions(+), 114 deletions(-)
 create mode 100644 tests/machine-none-test.c

-- 
2.7.4




[Qemu-devel] [PATCH v3 05/25] alpha: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Richard Henderson 
---
 target/alpha/cpu.h| 1 +
 tests/machine-none-test.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
index 0a9ad35..21ed5d6 100644
--- a/target/alpha/cpu.h
+++ b/target/alpha/cpu.h
@@ -472,6 +472,7 @@ void alpha_translate_init(void);
 
 #define ALPHA_CPU_TYPE_SUFFIX "-" TYPE_ALPHA_CPU
 #define ALPHA_CPU_TYPE_NAME(model) model ALPHA_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_ALPHA_CPU
 
 void alpha_cpu_list(FILE *f, fprintf_function cpu_fprintf);
 /* you can call this signal handler from your SIGBUS and SIGSEGV
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 4b704fb..5d23ade 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -28,6 +28,7 @@ static struct arch2cpu cpus_map[] = {
 { "aarch64", "cortex-a15" },
 { "x86_64", "qemu64,apic-id=0" },
 { "i386", "qemu32,apic-id=0" },
+{ "alpha", "ev67" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 07/25] lm32: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
test would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: Michael Walle 
---
 target/lm32/cpu.h | 1 +
 tests/machine-none-test.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/lm32/cpu.h b/target/lm32/cpu.h
index 2279594..0656052 100644
--- a/target/lm32/cpu.h
+++ b/target/lm32/cpu.h
@@ -259,6 +259,7 @@ bool lm32_cpu_do_semihosting(CPUState *cs);
 
 #define LM32_CPU_TYPE_SUFFIX "-" TYPE_LM32_CPU
 #define LM32_CPU_TYPE_NAME(model) model LM32_CPU_TYPE_SUFFIX
+#define CPU_RESOLVING_TYPE TYPE_LM32_CPU
 
 #define cpu_list lm32_cpu_list
 #define cpu_signal_handler cpu_lm32_signal_handler
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 68f7a30..1159290 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -30,6 +30,7 @@ static struct arch2cpu cpus_map[] = {
 { "i386", "qemu32,apic-id=0" },
 { "alpha", "ev67" },
 { "cris", "crisv32" },
+{ "lm32", "lm32-full" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 03/25] arm: cpu: add CPU_RESOLVING_TYPE macro

2018-01-23 Thread Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.

Along with change add target to null-machine test, so
that when switch to CPU_RESOLVING_TYPE happens,
thest would ensure that null-mchine usecase still works.

Signed-off-by: Igor Mammedov 
---
CC: qemu-...@nongnu.org
CC: Peter Maydell 
CC: Andrew Jones 
---
 target/arm/cpu.h  | 1 +
 linux-user/main.c | 2 --
 tests/machine-none-test.c | 2 ++
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 9631670..f9fb141 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -2171,6 +2171,7 @@ static inline bool arm_excp_unmasked(CPUState *cs, 
unsigned int excp_idx,
 
 #define ARM_CPU_TYPE_SUFFIX "-" TYPE_ARM_CPU
 #define ARM_CPU_TYPE_NAME(name) (name ARM_CPU_TYPE_SUFFIX)
+#define CPU_RESOLVING_TYPE TYPE_ARM_CPU
 
 #define cpu_signal_handler cpu_arm_signal_handler
 #define cpu_list arm_cpu_list
diff --git a/linux-user/main.c b/linux-user/main.c
index 450eb3c..a35477e 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -4325,8 +4325,6 @@ int main(int argc, char **argv, char **envp)
 #else
 cpu_model = "qemu32";
 #endif
-#elif defined(TARGET_ARM)
-cpu_model = "any";
 #elif defined(TARGET_UNICORE32)
 cpu_model = "any";
 #elif defined(TARGET_M68K)
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
index 2eb13e8..1b213ff 100644
--- a/tests/machine-none-test.c
+++ b/tests/machine-none-test.c
@@ -24,6 +24,8 @@ struct arch2cpu {
 
 static struct arch2cpu cpus_map[] = {
 /* tested targets list */
+{ "arm", "cortex-a15" },
+{ "aarch64", "cortex-a15" },
 };
 
 static const char *get_cpu_model_by_arch(const char *arch)
-- 
2.7.4




[Qemu-devel] [PATCH v3 02/25] tests: add machine 'none' with -cpu test

2018-01-23 Thread Igor Mammedov
Check that "$QEMU -M none -cpu FOO" starts QEMU without error

Signed-off-by: Igor Mammedov 
---
v2:
  - rename file to machine-none-test.c (Thomas Huth )
  - use qtest_startf()/instead of qtest_start() (Thomas Huth )
---
 tests/Makefile.include|  2 ++
 tests/machine-none-test.c | 68 +++
 2 files changed, 70 insertions(+)
 create mode 100644 tests/machine-none-test.c

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 8883274..ea0a803 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -380,6 +380,7 @@ check-qtest-s390x-y += tests/virtio-balloon-test$(EXESUF)
 check-qtest-s390x-y += tests/virtio-console-test$(EXESUF)
 check-qtest-s390x-y += tests/virtio-serial-test$(EXESUF)
 
+check-qtest-generic-y += tests/machine-none-test$(EXESUF)
 check-qtest-generic-y += tests/qom-test$(EXESUF)
 check-qtest-generic-y += tests/test-hmp$(EXESUF)
 
@@ -782,6 +783,7 @@ tests/display-vga-test$(EXESUF): tests/display-vga-test.o
 tests/ipoctal232-test$(EXESUF): tests/ipoctal232-test.o
 tests/qom-test$(EXESUF): tests/qom-test.o
 tests/test-hmp$(EXESUF): tests/test-hmp.o
+tests/machine-none-test$(EXESUF): tests/machine-none-test.o
 tests/drive_del-test$(EXESUF): tests/drive_del-test.o $(libqos-virtio-obj-y)
 tests/qdev-monitor-test$(EXESUF): tests/qdev-monitor-test.o $(libqos-pc-obj-y)
 tests/nvme-test$(EXESUF): tests/nvme-test.o
diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
new file mode 100644
index 000..2eb13e8
--- /dev/null
+++ b/tests/machine-none-test.c
@@ -0,0 +1,68 @@
+/*
+ * Machine 'none' tests.
+ *
+ * Copyright (c) 2018 Red Hat Inc.
+ *
+ * Authors:
+ *  Igor Mammedov ,
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+
+#include "qemu-common.h"
+#include "qemu/cutils.h"
+#include "libqtest.h"
+#include "qapi/qmp/types.h"
+
+struct arch2cpu {
+const char *arch;
+const char *cpu_model;
+};
+
+static struct arch2cpu cpus_map[] = {
+/* tested targets list */
+};
+
+static const char *get_cpu_model_by_arch(const char *arch)
+{
+int i;
+
+for (i = 0; i < ARRAY_SIZE(cpus_map); i++) {
+if (!strcmp(arch, cpus_map[i].arch)) {
+return cpus_map[i].cpu_model;
+}
+}
+return NULL;
+}
+
+static void test_machine_cpu_cli(void)
+{
+QDict *response;
+const char *arch = qtest_get_arch();
+const char *cpu_model = get_cpu_model_by_arch(arch);
+
+if (!cpu_model) {
+fprintf(stderr, "WARNING: cpu name for target '%s' isn't defined,"
+" add it to cpus_map\n", arch);
+return; /* TODO: die here to force all targets have a test */
+}
+global_qtest = qtest_startf("-machine none -cpu %s", cpu_model);
+
+response = qmp("{ 'execute': 'quit' }");
+g_assert(qdict_haskey(response, "return"));
+QDECREF(response);
+
+qtest_quit(global_qtest);
+}
+
+int main(int argc, char **argv)
+{
+g_test_init(&argc, &argv, NULL);
+
+qtest_add_func("machine/none/cpu_option", test_machine_cpu_cli);
+
+return g_test_run();
+}
-- 
2.7.4




<    1   2   3