Re: [Qemu-devel] [PULL 11/24] tcg: enable thread-per-vCPU

[Laurent Vivier]

Le 17/03/2017 à 21:43, Alex Bennée a écrit :
> 
> Laurent Vivier  writes:
> 
>> Le 27/02/2017 à 15:38, Alex Bennée a écrit :
>>>
>>> Laurent Vivier  writes:
>>>
 Le 24/02/2017 à 12:20, Alex Bennée a écrit :
> There are a couple of changes that occur at the same time here:
>
>   - introduce a single vCPU qemu_tcg_cpu_thread_fn
>
>   One of these is spawned per vCPU with its own Thread and Condition
>   variables. qemu_tcg_rr_cpu_thread_fn is the new name for the old
>   single threaded function.
>
>   - the TLS current_cpu variable is now live for the lifetime of MTTCG
> vCPU threads. This is for future work where async jobs need to know
> the vCPU context they are operating in.
>
> The user to switch on multi-thread behaviour and spawn a thread
> per-vCPU. For a simple test kvm-unit-test like:
>
>   ./arm/run ./arm/locking-test.flat -smp 4 -accel tcg,thread=multi
>
> Will now use 4 vCPU threads and have an expected FAIL (instead of the
> unexpected PASS) as the default mode of the test has no protection when
> incrementing a shared variable.
>
> We enable the parallel_cpus flag to ensure we generate correct barrier
> and atomic code if supported by the front and backends. This doesn't
> automatically enable MTTCG until default_mttcg_enabled() is updated to
> check the configuration is supported.

 This commit breaks linux-user mode:

 debian-8 with qemu-ppc on x86_64 with ltp-full-20170116

 cd /opt/ltp
 ./runltp -p -l "qemu-$(date +%FT%T).log" -f /opt/ltp/runtest/syscalls -s
 setgroups03

 setgroups031  TPASS  :  setgroups(65537) fails, Size is >
 sysconf(_SC_NGROUPS_MAX), errno=22
 qemu-ppc: /home/laurent/Projects/qemu/include/qemu/rcu.h:89:
 rcu_read_unlock: Assertion `p_rcu_reader->depth != 0' failed.
 qemu-ppc: /home/laurent/Projects/qemu/include/qemu/rcu.h:89:
 rcu_read_unlock: Assertion `p_rcu_reader->depth != 0' failed.
 qemu-ppc: /home/laurent/Projects/qemu/include/qemu/rcu.h:89:
 rcu_read_unlock: Assertion `p_rcu_reader->depth != 0' failed.
 ...
>>>
>>> Interesting. I can only think the current_cpu change has broken it
>>> because most of the changes in this commit affect softmmu targets only
>>> (linux-user has its own run loop).
>>>
>>> Thanks for the report - I'll look into it.
>>
>> After:
>>
>>  95b0eca Merge remote-tracking branch
>> 'remotes/stsquad/tags/pull-mttcg-fixups-090317-1' into staging
>>
>> [Tested with my HEAD on:
>> b1616fe Merge remote-tracking branch
>> 'remotes/famz/tags/docker-pull-request' into staging]
>>
>> I have now:
>>
>> <<>>
>> tag=setgroups03 stime=1489413401
>> cmdline="setgroups03"
>> contacts=""
>> analysis=exit
>> <<>>
>> **
>> ERROR:/home/laurent/Projects/qemu/cpu-exec.c:656:cpu_exec: assertion
>> failed: (cpu == current_cpu)
>> **
> 
> OK we now understand what's happening:
> 
>  - setgroups calls __nptl_setxid_error, triggers abort()
>- this sends sig_num 6, then 11
>  - host_signal_handler tries to handle 11
>  - -> handle_cpu_signal
> 
> Pre: tcg: enable thread-per-vCPU caused this problem:
> 
>  - current_cpu was reset to NULL on the way out of the loop
>  - therefore handle_cpu_signal went boom because
>  cpu = current_cpu;
>  cc = CPU_GET_CLASS(cpu);
> 
> Post: tcg: enable thread-per-vCPU caused this problem:
> 
>  - current_cpu is now live outside cpu_exec_loop
>- this is mainly so async_work functions can assert (cpu == current_cpu)
>  - hence handle_cpu_signal gets further and calls
> cpu_loop_exit(cpu);
>  - hilarity ensues as we siglongjmp into a stale context
> 
> Obviously we shouldn't try to siglongjmp. But we also shouldn't rely on
> current_cpu as a proxy to crash early when outside of the loop. There is
> a slight wrinkle that we also have funny handling of segs during
> translation if a guest jumps to code in an as-yet un-mapped region of
> memory.
> 
> There is currently cpu->running which is set/cleared by
> cpu_exec_start/end. Although if we crash between cpu_exec_start and
> sigsetjmp the same sort of brokenness might happen.
> 
> Anyway understood now. If anyone has any suggestions for neater stuff
> over the weekend please shout, otherwise I'll probably just hack
> handle_cpu_signal to do:
> 
>cpu = current_cpu;
>if (!cpu->running) {
>   /* we weren't running or translating JIT code when the signal came */
>   return 1;
>}

The return doesn't break the loop, but an abort() does.
I think we can put abort() here as it can be seen as an internal error
(and we get back the previous behavior).

Laurent

[Qemu-devel] [Bug 1673957] [NEW] virtfs: mapped-xattr on mount point

[Leo Gaspard]

Public bug reported:

With
  -virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared2"
in the qemu command line,
  shared2 on /mnt/testbis type 9p 
(rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L,msize=262144)
in the guest mount points, and
  tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
in the host mount points (with CONFIG_TMPFS_XATTR=y according to zgrep 
/proc/config.gz), running qemu as user "vm-test", trying to "touch a" in 
/mnt/testbis on the VM fails with "Operation not supported". In addition, no 
file or directory actually present in the host's /tmp can be seen in the 
guest's /mnt/testbis.

When trying to replace "/tmp" with "/tmp/aaa" on the host, with /tmp/aaa
owned by root:root, still running qemu as vm-test, trying to run "ls" in
the guest's /mnt/testbis fails with the weird "ls: reading directory
'.': Cannot allocate memory", while the directory is empty.

After a "chown vm-test /tmp/aaa", the guest can list the files (despite
the permissions already allowing it to do so before), but still not
write new files: "cannot touch 'b': Operation not supported".

Do you have a pointer as to what is happening?

PS: complete setup is running all this inside a qemu VM that I use for
testing, I guess it shouldn't matter but saying it just in case

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  virtfs: mapped-xattr on mount point

Status in QEMU:
  New

Bug description:
  With
-virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared2"
  in the qemu command line,
shared2 on /mnt/testbis type 9p 
(rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L,msize=262144)
  in the guest mount points, and
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
  in the host mount points (with CONFIG_TMPFS_XATTR=y according to zgrep 
/proc/config.gz), running qemu as user "vm-test", trying to "touch a" in 
/mnt/testbis on the VM fails with "Operation not supported". In addition, no 
file or directory actually present in the host's /tmp can be seen in the 
guest's /mnt/testbis.

  When trying to replace "/tmp" with "/tmp/aaa" on the host, with
  /tmp/aaa owned by root:root, still running qemu as vm-test, trying to
  run "ls" in the guest's /mnt/testbis fails with the weird "ls: reading
  directory '.': Cannot allocate memory", while the directory is empty.

  After a "chown vm-test /tmp/aaa", the guest can list the files
  (despite the permissions already allowing it to do so before), but
  still not write new files: "cannot touch 'b': Operation not
  supported".

  Do you have a pointer as to what is happening?

  PS: complete setup is running all this inside a qemu VM that I use for
  testing, I guess it shouldn't matter but saying it just in case

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

Re: [Qemu-devel] [Bug 1217339] [PATCH v2] Unix signal to send ACPI-shutdown to Guest

[Simon]

Hi,

The patch below adds the new command-line option `-powerdown' which
changes the behavior for both SIGHUP and SIGINT signals to cause a clean
power down of the guest using an ACPI shutdown request.

If this option is not used, the original behavior is kept.

Regards,
Simon.

Signed-off-by: Simon Geusebroek 
---
diff -ru a/qemu-options.hx b/qemu-options.hx
--- a/qemu-options.hx   2016-12-20 21:16:49.0 +0100
+++ b/qemu-options.hx   2017-03-18 14:17:35.759915414 +0100
@@ -3322,6 +3322,19 @@
 disk image.
 ETEXI

+DEF("powerdown", 0, QEMU_OPTION_powerdown, \
+"-powerdownCleanly power down the guest on SIGINT or SIGHUP\n", 
\

+QEMU_ARCH_ALL)
+STEXI
+@item -powerdown
+@findex -powerdown
+Don't forcefully shutdown the guest upon SIGINT (Ctrl-C) or SIGHUP 
(terminal
+closure) signals, but instead attempt to cleanly stop them using an 
ACPI

+shutdown request.
+Non ACPI-aware and stuck guests will remain up, the SIGTERM signal will 
still

+forcefully shutdown them.
+ETEXI
+
 DEF("loadvm", HAS_ARG, QEMU_OPTION_loadvm, \
 "-loadvm [tag|id]\n" \
 "start right away with a saved state (loadvm in 
monitor)\n",

diff -ru a/vl.c b/vl.c
--- a/vl.c  2016-12-20 21:16:54.0 +0100
+++ b/vl.c  2017-03-18 13:48:21.227967255 +0100
@@ -164,6 +164,7 @@
 int fd_bootchk = 1;
 static int no_reboot;
 int no_shutdown = 0;
+int powerdown = 0;
 int cursor_hide = 1;
 int graphic_rotate = 0;
 const char *watchdog;
@@ -1871,7 +1872,11 @@
 /* Cannot call qemu_system_shutdown_request directly because
  * we are in a signal handler.
  */
-shutdown_requested = 1;
+if (powerdown == 1 && (signal == SIGINT || signal == SIGHUP)) {
+powerdown_requested = 1;
+} else {
+shutdown_requested = 1;
+}
 qemu_notify_event();
 }

@@ -3794,6 +3799,9 @@
 case QEMU_OPTION_no_shutdown:
 no_shutdown = 1;
 break;
+case QEMU_OPTION_powerdown:
+powerdown = 1;
+break;
 case QEMU_OPTION_show_cursor:
 cursor_hide = 0;
 break;
--

Re: [Qemu-devel] [PULL 03/18] mem-prealloc: reduce large guest start-up and migration time.

[Peter Maydell]

On 14 March 2017 at 16:18, Paolo Bonzini  wrote:
> From: Jitendra Kolhe 
>
> Using "-mem-prealloc" option for a large guest leads to higher guest
> start-up and migration time. This is because with "-mem-prealloc" option
> qemu tries to map every guest page (create address translations), and
> make sure the pages are available during runtime. virsh/libvirt by
> default, seems to use "-mem-prealloc" option in case the guest is
> configured to use huge pages. The patch tries to map all guest pages
> simultaneously by spawning multiple threads. Currently limiting the
> change to QEMU library functions on POSIX compliant host only, as we are
> not sure if the problem exists on win32. Below are some stats with
> "-mem-prealloc" option for guest configured to use huge pages.

> --- a/util/oslib-posix.c
> +++ b/util/oslib-posix.c
> @@ -55,6 +55,21 @@
>  #include "qemu/error-report.h"
>  #endif
>
> +#define MAX_MEM_PREALLOC_THREAD_COUNT (MIN(sysconf(_SC_NPROCESSORS_ONLN), 
> 16))

sysconf() can fail, in which case it will return -1...

> +static bool touch_all_pages(char *area, size_t hpagesize, size_t numpages,
> +int smp_cpus)
> +{
> +uint64_t numpages_per_thread, size_per_thread;
> +char *addr = area;
> +int i = 0;
> +
> +memset_thread_failed = false;
> +memset_num_threads = MIN(smp_cpus, MAX_MEM_PREALLOC_THREAD_COUNT);

...and memset_num_threads (being signed) will also end up -1 here...

> +memset_thread = g_new0(MemsetThread, memset_num_threads);

...which we then pass to g_new0(), which will not have good
results.

(Spotted by Coverity, CID 1372465.)

Hiding a sysconf() behind a macro that looks like it's going
to be a constant integer is a bit confusing, incidentally,
and we only use it in one place. I'd just have a memset_num_threads()
function which calls sysconf and determines the right number from
that and smp_cpus and 16, and handles sysconf failing gracefully.

thanks
-- PMM

[Qemu-devel] [PATCH] hw/misc: Add Exynos4210 Pseudo Random Number Generator

[Krzysztof Kozlowski]

Add emulation for Exynos4210 Pseudo Random Number Generator which could
work on fixed seeds or with seeds provided by True Random Number
Generator block inside the SoC.

Implement only the fixed seeds part of it in polling mode (no
interrupts).  Simple testing:
# echo "exynos" > /sys/class/misc/hw_random/rng_current
# dd if=/dev/hwrng of=/dev/null bs=1 count=16

Signed-off-by: Krzysztof Kozlowski 
---
 hw/arm/exynos4210.c  |   4 +
 hw/misc/Makefile.objs|   2 +-
 hw/misc/exynos4210_rng.c | 262 +++
 3 files changed, 267 insertions(+), 1 deletion(-)
 create mode 100644 hw/misc/exynos4210_rng.c

diff --git a/hw/arm/exynos4210.c b/hw/arm/exynos4210.c
index 1d2b50cc4eea..0ec4250f0c05 100644
--- a/hw/arm/exynos4210.c
+++ b/hw/arm/exynos4210.c
@@ -78,6 +78,9 @@
 /* Clock controller SFR base address */
 #define EXYNOS4210_CLK_BASE_ADDR0x1003
 
+/* PRNG/HASH SFR base address */
+#define EXYNOS4210_RNG_BASE_ADDR0x10830400
+
 /* Display controllers (FIMD) */
 #define EXYNOS4210_FIMD0_BASE_ADDR  0x11C0
 
@@ -314,6 +317,7 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
 sysbus_create_simple("exynos4210.pmu", EXYNOS4210_PMU_BASE_ADDR, NULL);
 
 sysbus_create_simple("exynos4210.clk", EXYNOS4210_CLK_BASE_ADDR, NULL);
+sysbus_create_simple("exynos4210.rng", EXYNOS4210_RNG_BASE_ADDR, NULL);
 
 /* PWM */
 sysbus_create_varargs("exynos4210.pwm", EXYNOS4210_PWM_BASE_ADDR,
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index c8b489390f7e..e0699ea11155 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -26,7 +26,7 @@ obj-$(CONFIG_IVSHMEM) += ivshmem.o
 obj-$(CONFIG_REALVIEW) += arm_sysctl.o
 obj-$(CONFIG_NSERIES) += cbus.o
 obj-$(CONFIG_ECCMEMCTL) += eccmemctl.o
-obj-$(CONFIG_EXYNOS4) += exynos4210_pmu.o exynos4210_clk.o
+obj-$(CONFIG_EXYNOS4) += exynos4210_pmu.o exynos4210_clk.o exynos4210_rng.o
 obj-$(CONFIG_IMX) += imx_ccm.o
 obj-$(CONFIG_IMX) += imx31_ccm.o
 obj-$(CONFIG_IMX) += imx25_ccm.o
diff --git a/hw/misc/exynos4210_rng.c b/hw/misc/exynos4210_rng.c
new file mode 100644
index ..1fe00a6f1e6b
--- /dev/null
+++ b/hw/misc/exynos4210_rng.c
@@ -0,0 +1,262 @@
+/*
+ *  Exynos4210 Pseudo Random Nubmer Generator Emulation
+ *
+ *  Copyright (c) 2017 Krzysztof Kozlowski 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "qemu/log.h"
+
+#define TYPE_EXYNOS4210_RNG "exynos4210.rng"
+#define EXYNOS4210_RNG(obj) \
+OBJECT_CHECK(Exynos4210RngState, (obj), TYPE_EXYNOS4210_RNG)
+
+/*
+ * Exynos4220, PRNG, only polling mode is supported.
+ */
+
+/* RNG_CONTROL_1 register bitfields, reset value: 0x0 */
+#define EXYNOS4210_RNG_CONTROL_1_PRNG   0x8
+#define EXYNOS4210_RNG_CONTROL_1_START_INIT BIT(4)
+/* RNG_STATUS register bitfields, reset value: 0x1 */
+#define EXYNOS4210_RNG_STATUS_PRNG_ERRORBIT(7)
+#define EXYNOS4210_RNG_STATUS_PRNG_DONE BIT(5)
+#define EXYNOS4210_RNG_STATUS_MSG_DONE  BIT(4)
+#define EXYNOS4210_RNG_STATUS_PARTIAL_DONE  BIT(3)
+#define EXYNOS4210_RNG_STATUS_PRNG_BUSY BIT(2)
+#define EXYNOS4210_RNG_STATUS_SEED_SETTING_DONE BIT(1)
+#define EXYNOS4210_RNG_STATUS_BUFFER_READY  BIT(0)
+#define EXYNOS4210_RNG_STATUS_WRITE_MASK
(EXYNOS4210_RNG_STATUS_PRNG_DONE \
+| 
EXYNOS4210_RNG_STATUS_MSG_DONE \
+| 
EXYNOS4210_RNG_STATUS_PARTIAL_DONE)
+
+#define EXYNOS4210_RNG_CONTROL_1  0x0
+#define EXYNOS4210_RNG_STATUS0x10
+#define EXYNOS4210_RNG_SEED_IN  0x140
+#define EXYNOS4210_RNG_SEED_IN_OFFSET(n)(EXYNOS4210_RNG_SEED_IN + (n * 
0x4))
+#define EXYNOS4210_RNG_PRNG 0x160
+#define EXYNOS4210_RNG_PRNG_OFFSET(n)   (EXYNOS4210_RNG_PRNG + (n * 
0x4))
+
+#define EXYNOS4210_RNG_PRNG_NUM 5
+
+#define EXYNOS4210_RNG_REGS_MEM_SIZE0x200
+
+typedef struct Exynos4210RngState {
+SysBusDevice parent_obj;
+MemoryRegion iomem;
+
+int32_t randr_value[EXYNOS4210_RNG_PRNG_NUM];
+uint32_t seeds[EXYNOS4210_RNG_PRNG_NUM];
+
+/* Register values */
+uint32_t reg_control;
+uint32_t reg_status;
+} Exynos42

[Qemu-devel] [Bug 1673976] [NEW] core dump

[l3iggs]

Public bug reported:

I'm running a command (locale-gen) inside of an armv7h chroot mounted on
my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the
chroot file system and I get a core dump.

locale-gen
Generating locales...
  en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: 
Assertion `ec >= 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
/usr/bin/locale-gen: line 41:34 Aborted (core dumped) 
localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale

I've done this same thing successfully for years, but this breakage has
appeared some time in the last 3 or so months. Possibly with the update
to qemu version 2.8.

** Affects: qemu
 Importance: Undecided
 Status: New

** Description changed:

- I'm running a command command (locale-gen) inside of an armv7h chroot
- mounted on my x86_64 desktop by putting qemu-arm-static into /usr/bin/
- of the chroot file system and I get a core dump.
+ I'm running a command (locale-gen) inside of an armv7h chroot mounted on
+ my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the
+ chroot file system and I get a core dump.
  
  locale-gen
  Generating locales...
-   en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: 
__spawnix: Assertion `ec >= 0' failed.
+   en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: 
__spawnix: Assertion `ec >= 0' failed.
  qemu: uncaught target signal 6 (Aborted) - core dumped
  /usr/bin/locale-gen: line 41:34 Aborted (core dumped) 
localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale
  
  I've done this same thing successfully for years, but this breakage has
  appeared some time in the last 3 or so months. Possibly with the update
  to qemu version 2.8.

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

Title:
  core dump

Status in QEMU:
  New

Bug description:
  I'm running a command (locale-gen) inside of an armv7h chroot mounted
  on my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the
  chroot file system and I get a core dump.

  locale-gen
  Generating locales...
    en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: 
__spawnix: Assertion `ec >= 0' failed.
  qemu: uncaught target signal 6 (Aborted) - core dumped
  /usr/bin/locale-gen: line 41:34 Aborted (core dumped) 
localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale

  I've done this same thing successfully for years, but this breakage
  has appeared some time in the last 3 or so months. Possibly with the
  update to qemu version 2.8.

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

[Qemu-devel] [PATCH 1/2] userfault: add pid into uffd_msg

[Alexey Perevalov]

Signed-off-by: Alexey Perevalov 
---
 linux-headers/linux/userfaultfd.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/linux-headers/linux/userfaultfd.h 
b/linux-headers/linux/userfaultfd.h
index 2ed5dc3..7b299a2 100644
--- a/linux-headers/linux/userfaultfd.h
+++ b/linux-headers/linux/userfaultfd.h
@@ -77,6 +77,7 @@ struct uffd_msg {
struct {
__u64   flags;
__u64   address;
+   pid_t   pid;
} pagefault;
 
struct {
-- 
1.8.3.1

[Qemu-devel] [RFC PATCH 0/2] Calcuate downtime for postcopy live migration

[Alexey Perevalov]

Hi David,

I already asked you about downtime calculation for postcopy live migration.
As I remember you said it's worth not to calculate it per vCPU or maybe I
understood you incorrectly. I decided to proof it could be useful.

This patch set is based on commit 272d7dee5951f926fad1911f2f072e5915cdcba0
of QEMU master branch. It requires commit into Andreas git repository
"userfaultfd: provide pid in userfault uffd_msg"

When I tested it I found following moments are strange:
1. First userfault always occurs due to access to ram in vapic_map_rom_writable,
all vCPU are sleeping in this time
2. Latest half of all userfault was initiated by kworkers, that's why I had a 
doubt
about current in handle_userfault inside kernel as a proper task_struct for 
pagefault
initiator. All vCPU was sleeping at that moment.
3. Also there is a discrepancy, of vCPU state and real vCPU thread state.

This patch is just for showing and idea, if you ok with this idea none RFC 
patch will not
include proc access && a lot of traces.
Also I think it worth to guard postcopy_downtime in MigrationIncomingState and
return calculated downtime into src, where qeury-migration will be invocked.

Alexey Perevalov (2):
  userfault: add pid into uffd_msg
  migration: calculate downtime on dst side

 include/migration/migration.h |  11 ++
 linux-headers/linux/userfaultfd.h |   1 +
 migration/migration.c | 238 +-
 migration/postcopy-ram.c  |  61 +-
 migration/savevm.c|   2 +
 migration/trace-events|  10 +-
 6 files changed, 319 insertions(+), 4 deletions(-)

-- 
1.8.3.1

[Qemu-devel] [PATCH 2/2] migration: calculate downtime on dst side

[Alexey Perevalov]

This patch provides downtime calculation per vCPU,
as a summary and as a overlapped value for all vCPUs.

This approach just keeps tree with page fault addr as a key,
and t1-t2 interval of pagefault time and page copy time, with
affected vCPU bit mask.
For more implementation details please see comment to
get_postcopy_total_downtime function.

Signed-off-by: Alexey Perevalov 
---
 include/migration/migration.h |  11 ++
 migration/migration.c | 238 +-
 migration/postcopy-ram.c  |  61 ++-
 migration/savevm.c|   2 +
 migration/trace-events|  10 +-
 5 files changed, 318 insertions(+), 4 deletions(-)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index 5720c88..8f9af77 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -123,10 +123,21 @@ struct MigrationIncomingState {
 
 /* See savevm.c */
 LoadStateEntry_Head loadvm_handlers;
+
+/*
+ *  Tree for keeping postcopy downtime,
+ *  necessary to calculate correct downtime, during multiple
+ *  vm suspends, it keeps host page address as a key and
+ *  DowntimeDuration as a data
+ */
+GTree *postcopy_downtime;
 };
 
 MigrationIncomingState *migration_incoming_get_current(void);
 void migration_incoming_state_destroy(void);
+void mark_postcopy_downtime_begin(uint64_t addr, int cpu);
+void mark_postcopy_downtime_end(uint64_t addr);
+int64_t get_postcopy_total_downtime(void);
 
 /*
  * An outstanding page request, on the source, having been received
diff --git a/migration/migration.c b/migration/migration.c
index 54060f7..57d71e1 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -77,6 +77,12 @@ static NotifierList migration_state_notifiers =
 
 static bool deferred_incoming;
 
+typedef struct {
+int64_t begin;
+int64_t end;
+uint64_t cpus;
+} DowntimeDuration;
+
 /*
  * Current state of incoming postcopy; note this is not part of
  * MigrationIncomingState since it's state is used during cleanup
@@ -117,6 +123,21 @@ MigrationState *migrate_get_current(void)
 return ¤t_migration;
 }
 
+static gint addr_compare(gconstpointer a, gconstpointer b,
+ gpointer user_data G_GNUC_UNUSED)
+{
+if (a == b)
+return 0;
+else if (a > b)
+return 1;
+return -1;
+}
+
+static void destroy_downtime_duration(gpointer data)
+{
+free(data);
+}
+
 MigrationIncomingState *migration_incoming_get_current(void)
 {
 static bool once;
@@ -128,6 +149,9 @@ MigrationIncomingState *migration_incoming_get_current(void)
 QLIST_INIT(&mis_current.loadvm_handlers);
 qemu_mutex_init(&mis_current.rp_mutex);
 qemu_event_init(&mis_current.main_thread_load_event, false);
+mis_current.postcopy_downtime = g_tree_new_full(addr_compare,
+ NULL, NULL,
+ destroy_downtime_duration);
 once = true;
 }
 return &mis_current;
@@ -138,10 +162,13 @@ void migration_incoming_state_destroy(void)
 struct MigrationIncomingState *mis = migration_incoming_get_current();
 
 qemu_event_destroy(&mis->main_thread_load_event);
+if (mis->postcopy_downtime) {
+g_tree_destroy(mis->postcopy_downtime);
+mis->postcopy_downtime = NULL;
+}
 loadvm_free_handlers(mis);
 }
 
-
 typedef struct {
 bool optional;
 uint32_t size;
@@ -1119,7 +1146,6 @@ MigrationState *migrate_init(const MigrationParams 
*params)
 s->last_req_rb = NULL;
 error_free(s->error);
 s->error = NULL;
-
 migrate_set_state(&s->state, MIGRATION_STATUS_NONE, 
MIGRATION_STATUS_SETUP);
 
 QSIMPLEQ_INIT(&s->src_page_requests);
@@ -2109,3 +2135,211 @@ PostcopyState postcopy_state_set(PostcopyState 
new_state)
 return atomic_xchg(&incoming_postcopy_state, new_state);
 }
 
+void mark_postcopy_downtime_begin(uint64_t addr, int cpu)
+{
+MigrationIncomingState *mis = migration_incoming_get_current();
+DowntimeDuration *dd;
+if (!mis || !mis->postcopy_downtime) {
+error_report("Migration incoming state should exists mis %p", mis);
+return;
+}
+
+dd = g_tree_lookup(mis->postcopy_downtime, (gpointer)addr); /* !!! cast */
+if (!dd) {
+dd = (DowntimeDuration *)g_malloc0(sizeof(DowntimeDuration));
+g_tree_insert(mis->postcopy_downtime, (gpointer)addr, (gpointer)dd);
+}
+
+if (cpu < 0)
+/* assume in this situation all vCPUs are sleeping */
+dd->cpus = ~0u;
+else
+set_bit(cpu, &dd->cpus);
+
+/*
+ *  overwrite previously set dd->begin, if that page already was
+ * faulted on another cpu
+ */
+dd->begin = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
+trace_mark_postcopy_downtime_begin(addr, dd, dd->begin, cpu);
+}
+
+void mark_postcopy_downtime_end(uint64_t addr)
+{
+MigrationIncomingState *mis = migration_incoming

Re: [Qemu-devel] callout to *file in bdrv_co_get_block_status

[Peter Lieven]

Am 17.03.2017 um 15:51 schrieb Paolo Bonzini:
>
> On 17/03/2017 12:24, Fam Zheng wrote:
>> On Fri, 03/17 12:16, Paolo Bonzini wrote:
>>>
>>> On 17/03/2017 12:11, Peter Lieven wrote:
>> like VMDK or QCOW2 shouldn't we trust the information from the l2 tables 
>> in the VMDK or QCOW2?
> It provides additional information, for example it works better with
> prealloc=metadata.
 Okay, understood. Can you imagine of a away to conditionally avoid this 
 second callout? In my case we have an additional
 lseek for each cluster. For a 20GB file this are approx. 327k calls to 
 lseek. And if the file has no preallocated metadata
 it will likely not improve anything. And even if the metadata is 
 prealloced what is the allocation status of the clusters?
>>> If the metadata is preallocated, cluster will (or should) show up as
>>> zero, speeding up the copy.
>> I think from qemu-img convert's perspective, it doesn't care about the *file
>> status if the metadata already speaks, because, like you said, the data 
>> shows up
>> as zeroes.
> That's already the case: *file is only examined if the metadata  says
> BDRV_BLOCK_DATA=1, BDRV_BLOCK_ZERO=0.

Maybe Fam meant in qemu-img this info is not that necessary because it will 
skip zeroes inside
a datablock anyway. I don't know why the lseek is soo slow, but the 
optimization could be to identify
the case where this extra info of the *file containing zeroes is really useful 
and then only call out for
it in those cases.

Peter

>
> Paolo

Re: [Qemu-devel] [RFC PATCH 0/2] Calcuate downtime for postcopy live migration

[no-reply]

Hi,

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

Message-id: 1489850003-5652-1-git-send-email-a.pereva...@samsung.com
Subject: [Qemu-devel] [RFC PATCH 0/2] Calcuate downtime for postcopy live 
migration
Type: series

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

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

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/1489850003-5652-1-git-send-email-a.pereva...@samsung.com -> 
patchew/1489850003-5652-1-git-send-email-a.pereva...@samsung.com
Switched to a new branch 'test'
2bb4f0b migration: calculate downtime on dst side
f39835b userfault: add pid into uffd_msg

=== OUTPUT BEGIN ===
Checking PATCH 1/2: userfault: add pid into uffd_msg...
Checking PATCH 2/2: migration: calculate downtime on dst side...
Argument "m" isn't numeric in numeric eq (==) at ./scripts/checkpatch.pl line 
2459.
Argument "m" isn't numeric in numeric eq (==) at ./scripts/checkpatch.pl line 
2459.
Use of uninitialized value $1 in concatenation (.) or string at 
./scripts/checkpatch.pl line 2460.
ERROR: braces {} are necessary for all arms of this statement
#68: FILE: migration/migration.c:129:
+if (a == b)
[...]
+else if (a > b)
[...]

ERROR: braces {} are necessary for all arms of this statement
#70: FILE: migration/migration.c:131:
+else if (a > b)
[...]

ERROR: unnecessary cast may hide bugs, use g_new0 instead
#131: FILE: migration/migration.c:2149:
+dd = (DowntimeDuration *)g_malloc0(sizeof(DowntimeDuration));

ERROR: braces {} are necessary for all arms of this statement
#135: FILE: migration/migration.c:2153:
+if (cpu < 0)
[...]
+else
[...]

WARNING: line over 80 characters
#160: FILE: migration/migration.c:2178:
+/* error_report("Could not populate downtime duration completion time 
\n\

ERROR: unnecessary whitespace before a quoted newline
#160: FILE: migration/migration.c:2178:
+/* error_report("Could not populate downtime duration completion time 
\n\

ERROR: Error messages should not contain newlines
#160: FILE: migration/migration.c:2178:
+/* error_report("Could not populate downtime duration completion time 
\n\

ERROR: braces {} are necessary for all arms of this statement
#193: FILE: migration/migration.c:2211:
+if (dd->end && dd->begin)
[...]

WARNING: line over 80 characters
#194: FILE: migration/migration.c:2212:
+trace_sumup_downtime_duration(dd->end - dd->begin, (uint64_t)key, 
dd->cpus);

ERROR: braces {} are necessary for all arms of this statement
#205: FILE: migration/migration.c:2223:
+if (test_bit(cpu_iter, &dd->cpus) && dd->end && dd->begin)
[...]

ERROR: that open brace { should be on the previous line
#222: FILE: migration/migration.c:2240:
+for (i = 0; i < smp_cpus; i++)
+{

ERROR: braces {} are necessary even for single statement blocks
#222: FILE: migration/migration.c:2240:
+for (i = 0; i < smp_cpus; i++)
+{
+   set_bit(i, &sufficient_cpus);
+}

ERROR: code indent should never use tabs
#224: FILE: migration/migration.c:2242:
+^Iset_bit(i, &sufficient_cpus);$

WARNING: line over 80 characters
#262: FILE: migration/migration.c:2280:
+ * S2,E1 - doesn't match condition due to sequence S1,S2,E1 doesn't include 
CPU3,

ERROR: that open brace { should be on the previous line
#288: FILE: migration/migration.c:2306:
+for (point_iter = 0; point_iter < smp_cpus; point_iter++)
+{

ERROR: braces {} are necessary even for single statement blocks
#288: FILE: migration/migration.c:2306:
+for (point_iter = 0; point_iter < smp_cpus; point_iter++)
+{
+trace_downtime_per_cpu(point_iter, downtime_cpu[point_iter]);
+}

ERROR: braces {} are necessary for all arms of this statement
#302: FILE: migration/migration.c:2320:
+if (!od->is_end || prev_od->is_end)
[...]

ERROR: braces {} are necessary for all arms of this statement
#311: FILE: migration/migration.c:2329:
+if (t_od->is_end)
[...]

ERROR: braces {} are necessary for all arms of this statement
#367: FILE: migration/postcopy-ram.c:431:
+if (strstr(line, "Name"))
[...]

ERROR: braces {} are necessary for all arms of this statement
#369: FILE: migration/postcopy-ram.c:433:
+if (strstr(line, "State"))
[...]

ERROR: suspect code indent for conditional statements (8, 11)
#382: FILE: migration/postcopy-ram.c:446:
+if (cpu_iter->thread_id == pid)
+   return cpu_iter->cpu_index;

ERROR: braces {} are necessary for all 

Re: [Qemu-devel] [Qemu-block] [PATCH] curl: fix compilation on OpenBSD

[Peter Maydell]

On 18 March 2017 at 02:27, Max Reitz  wrote:
> On 17.03.2017 16:24, Paolo Bonzini wrote:
>> EPROTO is not found in OpenBSD.   We usually use EIO when no better
>> errno is available, do that here too.
>>
>> Reported-by: Peter Maydell 
>> Signed-off-by: Paolo Bonzini 
>> ---
>>  block/curl.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Thanks, applied to my block branch:
>
> https://github.com/XanClic/qemu/commits/block

Thanks; I've applied it to master as a build fix, though,
so you can drop it (or leave it and let the merge
sort it out if you like).

thanks
-- PMM

Re: [Qemu-devel] [PATCH] oslib-posix: fix compilation on OpenBSD

[Peter Maydell]

On 17 March 2017 at 15:22, Paolo Bonzini  wrote:
> si_band is not found in OpenBSD.   It is marked as obsolescent in
> POSIX, so we can delete it without any remorse.
>
> Reported-by: Peter Maydell 
> Signed-off-by: Paolo Bonzini 
> ---
>  util/oslib-posix.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/util/oslib-posix.c b/util/oslib-posix.c
> index 94d81b9..3fe6089 100644
> --- a/util/oslib-posix.c
> +++ b/util/oslib-posix.c
> @@ -709,8 +709,6 @@ void sigaction_invoke(struct sigaction *action,
>  si.si_pid = info->ssi_pid;
>  si.si_status = info->ssi_status;
>  si.si_uid = info->ssi_uid;
> -} else if (info->ssi_signo == SIGIO) {
> -si.si_band = info->ssi_band;
>  }
>  action->sa_sigaction(info->ssi_signo, &si, NULL);
>  }
> --
> 2.9.3

Applied to master as a buildfix, thanks.

-- PMM

Re: [Qemu-devel] [Qemu-arm] [PATCH 0/4] arm: Fix M profile MSR/MRS

[Peter Maydell]

Last ping for review; otherwise I'll put them into rc1 anyway
since it's fixing a regression.

thanks
-- PMM

On 14 March 2017 at 11:52, Peter Maydell  wrote:
> Ping for review -- since this is a bugfix it should go
> into 2.9.
>
> thanks
> -- PMM
>
> On 20 February 2017 at 19:41, Peter Maydell  wrote:
>> This patchseries fixes up some deficiencies and one nasty
>> bug in the M profile MSR/MRS handling.
>>
>> The first three patches are just cleaning up the decode
>> so that we UNDEF where we should in the MRS/MSR space
>> for M profile -- this won't have caused any problems in
>> practice since real world code doesn't generally execute
>> UNDEFfing instructions on purpose.
>>
>> The fourth patch fixes a nasty bug that I introduced in
>> commit 58117c9bb429cd which broke APSR writes via MSR,
>> and brings them into line with the pseudocode by allowing
>> writes to the APSR GE[3:0] bits when the CPU implements
>> the DSP extensions.
>>
>> Alex -- I should have paid closer attention to your review
>> comments on the patch that became commit 58117c9bb429cd;
>> sorry about that. I knew we didn't get the GE[3:0] stuff
>> right yet but I didn't spot that we'd managed to invert
>> the sense of the SYSm bit 2 test in that patch :-(
>>
>> thanks
>> -- PMM
>>
>> Peter Maydell (4):
>>   arm: HVC and SMC encodings don't exist for M profile
>>   arm: Don't decode MRS(banked) or MSR(banked) for M profile
>>   arm: Enforce should-be-1 bits in MRS decoding
>>   arm: Fix APSR writes via M profile MSR
>>
>>  target/arm/helper.c| 26 ++
>>  target/arm/translate.c | 26 +++---
>>  2 files changed, 45 insertions(+), 7 deletions(-)

Re: [Qemu-devel] [PULL for 2.9 0/2] target/xtensa fixes

[Peter Maydell]

On 17 March 2017 at 18:18, Max Filippov  wrote:
> Hi Peter,
>
> please pull the following two fixes for the target/xtensa.
>
> The following changes since commit dd4d2578215cd380f40a38028a9904e15b135ef3:
>
>   Merge remote-tracking branch 'remotes/kraxel/tags/pull-fixes-20170309-1' 
> into staging (2017-03-09 13:16:05 +)
>
> are available in the git repository at:
>
>   git://github.com/OSLL/qemu-xtensa.git tags/20170317-xtensa
>
> for you to fetch changes up to f289bb091e6876df2e0e3481cb414c277695a405:
>
>   target/xtensa: fix semihosting argc/argv implementation (2017-03-11 
> 14:59:03 -0800)
>
> 
> target/xtensa fixes for 2.9:
>
> - fix build failure when FDT support is not enabled;
> - correctly pass command line arguments to semihosting guests.
>
> 
> Max Filippov (2):
>   target/xtensa: xtfpga: load DTB only when FDT support is enabled
>   target/xtensa: fix semihosting argc/argv implementation
>
>  hw/xtensa/xtfpga.c  |  9 +
>  target/xtensa/xtensa-semi.c | 49 
> +
>  2 files changed, 45 insertions(+), 13 deletions(-)

Applied, thanks.

-- PMM

[Qemu-devel] [PATCH v2] hw/misc: Add Exynos4210 Pseudo Random Number Generator

[Krzysztof Kozlowski]

Add emulation for Exynos4210 Pseudo Random Number Generator which could
work on fixed seeds or with seeds provided by True Random Number
Generator block inside the SoC.

Implement only the fixed seeds part of it in polling mode (no
interrupts).  Simple testing:
# echo "exynos" > /sys/class/misc/hw_random/rng_current
# dd if=/dev/hwrng of=/dev/null bs=1 count=16

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Use GRand-like functions to fix build on MingW32 (this adds also
   finalize).
2. Add DPRINTF macro.
3. Use HWADDR_PRIx and family for printing values.
---
 hw/arm/exynos4210.c  |   4 +
 hw/misc/Makefile.objs|   2 +-
 hw/misc/exynos4210_rng.c | 303 +++
 3 files changed, 308 insertions(+), 1 deletion(-)
 create mode 100644 hw/misc/exynos4210_rng.c

diff --git a/hw/arm/exynos4210.c b/hw/arm/exynos4210.c
index 1d2b50cc4eea..0ec4250f0c05 100644
--- a/hw/arm/exynos4210.c
+++ b/hw/arm/exynos4210.c
@@ -78,6 +78,9 @@
 /* Clock controller SFR base address */
 #define EXYNOS4210_CLK_BASE_ADDR0x1003
 
+/* PRNG/HASH SFR base address */
+#define EXYNOS4210_RNG_BASE_ADDR0x10830400
+
 /* Display controllers (FIMD) */
 #define EXYNOS4210_FIMD0_BASE_ADDR  0x11C0
 
@@ -314,6 +317,7 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
 sysbus_create_simple("exynos4210.pmu", EXYNOS4210_PMU_BASE_ADDR, NULL);
 
 sysbus_create_simple("exynos4210.clk", EXYNOS4210_CLK_BASE_ADDR, NULL);
+sysbus_create_simple("exynos4210.rng", EXYNOS4210_RNG_BASE_ADDR, NULL);
 
 /* PWM */
 sysbus_create_varargs("exynos4210.pwm", EXYNOS4210_PWM_BASE_ADDR,
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index c8b489390f7e..e0699ea11155 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -26,7 +26,7 @@ obj-$(CONFIG_IVSHMEM) += ivshmem.o
 obj-$(CONFIG_REALVIEW) += arm_sysctl.o
 obj-$(CONFIG_NSERIES) += cbus.o
 obj-$(CONFIG_ECCMEMCTL) += eccmemctl.o
-obj-$(CONFIG_EXYNOS4) += exynos4210_pmu.o exynos4210_clk.o
+obj-$(CONFIG_EXYNOS4) += exynos4210_pmu.o exynos4210_clk.o exynos4210_rng.o
 obj-$(CONFIG_IMX) += imx_ccm.o
 obj-$(CONFIG_IMX) += imx31_ccm.o
 obj-$(CONFIG_IMX) += imx25_ccm.o
diff --git a/hw/misc/exynos4210_rng.c b/hw/misc/exynos4210_rng.c
new file mode 100644
index ..09b3751fe76a
--- /dev/null
+++ b/hw/misc/exynos4210_rng.c
@@ -0,0 +1,303 @@
+/*
+ *  Exynos4210 Pseudo Random Nubmer Generator Emulation
+ *
+ *  Copyright (c) 2017 Krzysztof Kozlowski 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "qemu/log.h"
+
+#define DEBUG_EXYNOS_RNG 0
+
+#define DPRINTF(fmt, ...) \
+do { \
+if (DEBUG_EXYNOS_RNG) { \
+printf("exynos4210_rng: " fmt, ## __VA_ARGS__); \
+} \
+} while (0)
+
+#define TYPE_EXYNOS4210_RNG "exynos4210.rng"
+#define EXYNOS4210_RNG(obj) \
+OBJECT_CHECK(Exynos4210RngState, (obj), TYPE_EXYNOS4210_RNG)
+
+/*
+ * Exynos4220, PRNG, only polling mode is supported.
+ */
+
+/* RNG_CONTROL_1 register bitfields, reset value: 0x0 */
+#define EXYNOS4210_RNG_CONTROL_1_PRNG   0x8
+#define EXYNOS4210_RNG_CONTROL_1_START_INIT BIT(4)
+/* RNG_STATUS register bitfields, reset value: 0x1 */
+#define EXYNOS4210_RNG_STATUS_PRNG_ERRORBIT(7)
+#define EXYNOS4210_RNG_STATUS_PRNG_DONE BIT(5)
+#define EXYNOS4210_RNG_STATUS_MSG_DONE  BIT(4)
+#define EXYNOS4210_RNG_STATUS_PARTIAL_DONE  BIT(3)
+#define EXYNOS4210_RNG_STATUS_PRNG_BUSY BIT(2)
+#define EXYNOS4210_RNG_STATUS_SEED_SETTING_DONE BIT(1)
+#define EXYNOS4210_RNG_STATUS_BUFFER_READY  BIT(0)
+#define EXYNOS4210_RNG_STATUS_WRITE_MASK
(EXYNOS4210_RNG_STATUS_PRNG_DONE \
+| 
EXYNOS4210_RNG_STATUS_MSG_DONE \
+| 
EXYNOS4210_RNG_STATUS_PARTIAL_DONE)
+
+#define EXYNOS4210_RNG_CONTROL_1  0x0
+#define EXYNOS4210_RNG_STATUS0x10
+#define EXYNOS4210_RNG_SEED_IN  0x140
+#define EXYNOS4210_RNG_SEED_IN_OFFSET(n)(EXYNOS4210_RNG_SEED_IN + (n * 
0x4))
+#define EXYNOS4210_RNG_PRNG 0x160
+#define EXYNOS4210_RNG_PRNG_OFFSET(n)   (EXYNOS4210_RNG_PRNG + (n * 
0x4))
+
+#define EXYNO

Re: [Qemu-devel] [PATCH V3] nios2: iic: Convert CPU prop to qom link

[Peter Maydell]

On 17 March 2017 at 21:06, Marek Vasut  wrote:
> Add a const qom link between the CPU and the IIC instead
> of passing the CPU link through a qom property.
>
> Signed-off-by: Marek Vasut 
> Cc: Alexander Graf 
> Cc: Chris Wulff 
> Cc: Igor Mammedov 
> Cc: Jeff Da Silva 
> Cc: Ley Foon Tan 
> Cc: Markus Armbruster 
> Cc: Richard Henderson 
> Cc: Sandra Loosemore 
> Cc: Yves Vandervennet 
> Reviewed-by: Markus Armbruster 
> ---
> V2: Retain dc->cannot_instantiate_with_device_add_yet = true
> in altera_iic_class_init() since the device is still not
> device_add() creatable.
> V3: Update the comment in altera_iic_class_init()

Applied to master, thanks.

-- PMM

Re: [Qemu-devel] [RFC v2 4/8] qcow2: extract image creation option parsing

[Nir Soffer]

On Wed, Mar 15, 2017 at 11:30 AM Stefan Hajnoczi 
wrote:

> The image creation options parsed by qcow2_create() are also needed to
> implement .bdrv_measure().  Extract the parsing code, including input
> validation.
>
> Signed-off-by: Stefan Hajnoczi 
> ---
>  block/qcow2.c | 109
> +++---
>  1 file changed, 73 insertions(+), 36 deletions(-)
>
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 7c702f4..19be468 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -2168,24 +2168,73 @@ static int64_t qcow2_calc_prealloc_size(int64_t
> total_size,
>  return meta_size + aligned_total_size;
>  }
>
> -static int qcow2_create2(const char *filename, int64_t total_size,
> - const char *backing_file, const char
> *backing_format,
> - int flags, size_t cluster_size, PreallocMode
> prealloc,
> - QemuOpts *opts, int version, int refcount_order,
> - Error **errp)
> +static size_t qcow2_opt_get_cluster_size_del(QemuOpts *opts, Error **errp)
>  {
> +size_t cluster_size;
>  int cluster_bits;
> -QDict *options;
>
> -/* Calculate cluster_bits */
> +cluster_size = qemu_opt_get_size_del(opts, BLOCK_OPT_CLUSTER_SIZE,
> + DEFAULT_CLUSTER_SIZE);
>  cluster_bits = ctz32(cluster_size);
>  if (cluster_bits < MIN_CLUSTER_BITS || cluster_bits >
> MAX_CLUSTER_BITS ||
>  (1 << cluster_bits) != cluster_size)
>  {
>  error_setg(errp, "Cluster size must be a power of two between %d
> and "
> "%dk", 1 << MIN_CLUSTER_BITS, 1 << (MAX_CLUSTER_BITS -
> 10));
> -return -EINVAL;
> +return 0;
>  }
> +return cluster_size;
> +}
> +
> +static int qcow2_opt_get_version_del(QemuOpts *opts, Error **errp)
> +{
> +char *buf;
> +int ret;
> +
> +buf = qemu_opt_get_del(opts, BLOCK_OPT_COMPAT_LEVEL);
> +if (!buf) {
> +ret = 3; /* default */
> +} else if (!strcmp(buf, "0.10")) {
> +ret = 2;
> +} else if (!strcmp(buf, "1.1")) {
> +ret = 3;
> +} else {
> +error_setg(errp, "Invalid compatibility level: '%s'", buf);
> +ret = -EINVAL;
> +}
> +g_free(buf);
> +return ret;
> +}
> +
> +static uint64_t qcow2_opt_get_refcount_bits_del(QemuOpts *opts, int
> version,
> +Error **errp)
> +{
> +uint64_t refcount_bits;
> +
> +refcount_bits = qemu_opt_get_number_del(opts,
> BLOCK_OPT_REFCOUNT_BITS, 16);
> +if (refcount_bits > 64 || !is_power_of_2(refcount_bits)) {
> +error_setg(errp, "Refcount width must be a power of two and may
> not "
> +   "exceed 64 bits");
> +return 0;
> +}
> +
> +if (version < 3 && refcount_bits != 16) {
> +error_setg(errp, "Different refcount widths than 16 bits require "
> +   "compatibility level 1.1 or above (use compat=1.1 or "
> +   "greater)");
> +return 0;
> +}
> +
> +return refcount_bits;
> +}
> +
> +static int qcow2_create2(const char *filename, int64_t total_size,
> + const char *backing_file, const char
> *backing_format,
> + int flags, size_t cluster_size, PreallocMode
> prealloc,
> + QemuOpts *opts, int version, int refcount_order,
> + Error **errp)
> +{
> +QDict *options;
>
>  /*
>   * Open the image file and write a minimal qcow2 header.
> @@ -2235,7 +2284,7 @@ static int qcow2_create2(const char *filename,
> int64_t total_size,
>  *header = (QCowHeader) {
>  .magic  = cpu_to_be32(QCOW_MAGIC),
>  .version= cpu_to_be32(version),
> -.cluster_bits   = cpu_to_be32(cluster_bits),
> +.cluster_bits   = cpu_to_be32(ctz32(cluster_size)),
>

Is this related?


>  .size   = cpu_to_be64(0),
>  .l1_table_offset= cpu_to_be64(0),
>  .l1_size= cpu_to_be32(0),
> @@ -2371,8 +2420,8 @@ static int qcow2_create(const char *filename,
> QemuOpts *opts, Error **errp)
>  int flags = 0;
>  size_t cluster_size = DEFAULT_CLUSTER_SIZE;
>  PreallocMode prealloc;
> -int version = 3;
> -uint64_t refcount_bits = 16;
> +int version;
> +uint64_t refcount_bits;
>  int refcount_order;
>  Error *local_err = NULL;
>  int ret;
> @@ -2385,8 +2434,12 @@ static int qcow2_create(const char *filename,
> QemuOpts *opts, Error **errp)
>  if (qemu_opt_get_bool_del(opts, BLOCK_OPT_ENCRYPT, false)) {
>  flags |= BLOCK_FLAG_ENCRYPT;
>  }
> -cluster_size = qemu_opt_get_size_del(opts, BLOCK_OPT_CLUSTER_SIZE,
> - DEFAULT_CLUSTER_SIZE);
> +cluster_size = qcow2_opt_get_cluster_size_del(opts, &local_

[Qemu-devel] Error checking and qemu_thread_create

[Anton Volkov]

Hello.

I want to make qemu_thread_create return a flag as described here 
(http://wiki.qemu-project.org/BiteSizedTasks), but I’m not sure how callers 
should behave if it fails.
I could make it so they would call something like error_report() and then call 
abort(), but then it is almost a copy of existing behavior.
Would the described behavior be acceptable? Or it should be different?

Best regards,
Anton Volkov

Re: [Qemu-devel] [RFC v2 8/8] iotests: add test 178 for qemu-img measure

[Nir Soffer]

On Wed, Mar 15, 2017 at 11:30 AM Stefan Hajnoczi 
wrote:

> Signed-off-by: Stefan Hajnoczi 
> ---
>  tests/qemu-iotests/178   | 75
> 
>  tests/qemu-iotests/178.out.qcow2 | 33 ++
>  tests/qemu-iotests/178.out.raw   | 33 ++
>  tests/qemu-iotests/group |  1 +
>  4 files changed, 142 insertions(+)
>  create mode 100755 tests/qemu-iotests/178
>  create mode 100644 tests/qemu-iotests/178.out.qcow2
>  create mode 100644 tests/qemu-iotests/178.out.raw
>
> diff --git a/tests/qemu-iotests/178 b/tests/qemu-iotests/178
> new file mode 100755
> index 000..8db1241
> --- /dev/null
> +++ b/tests/qemu-iotests/178
> @@ -0,0 +1,75 @@
> +#!/bin/bash
> +#
> +# qemu-img measure sub-command tests
> +#
> +# Copyright (C) 2017 Red Hat, Inc.
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 2 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see .
> +#
> +
> +# creator
> +owner=stefa...@redhat.com
> +
> +seq=`basename $0`
> +echo "QA output created by $seq"
> +
> +here=`pwd`
> +status=1# failure is the default!
> +
> +_cleanup()
> +{
> +_cleanup_test_img
> +}
> +trap "_cleanup; exit \$status" 0 1 2 3 15
> +
> +# get standard environment, filters and checks
> +. ./common.rc
> +. ./common.filter
> +. ./common.pattern
> +
> +_supported_fmt raw qcow2
> +_supported_proto file
> +_supported_os Linux
> +
> +echo "Input validation"
>

Maybe:

echo "== Input validation =="

for nicer output?


> +echo
> +
> +_make_test_img 1G
> +
> +$QEMU_IMG measure # missing arguments
> +$QEMU_IMG measure --size 2G "$TEST_IMG" # only one allowed
> +$QEMU_IMG measure "$TEST_IMG" a # only one filename allowed
> +$QEMU_IMG measure --object secret,id=sec0,data=MTIzNDU2,format=base64 #
> missing filename
> +$QEMU_IMG measure --image-opts # missing filename
> +$QEMU_IMG measure -f qcow2 # missing filename
> +$QEMU_IMG measure -l snap1 # missing filename
> +$QEMU_IMG measure -o , # invalid option list
> +$QEMU_IMG measure -l snapshot.foo # invalid snapshot option
> +$QEMU_IMG measure --output foo # invalid output format
> +$QEMU_IMG measure --size -1 # invalid image size
> +$QEMU_IMG measure -O foo "$TEST_IMG" # unknown image file format
> +
> +echo
> +echo "Size calculation"
> +echo
> +
> +for ofmt in human json; do
> +$QEMU_IMG measure --output=$ofmt -O "$IMGFMT" --size 2G
>

--size 0 may be interesting test


> +$QEMU_IMG measure --output=$ofmt -f "$IMGFMT" -O "$IMGFMT" "$TEST_IMG"
>

This measure converting raw to raw or qcow2 to qcow2, not sure it is very
interesting, since in raw we don't need to measure, the size is always
the virtual size, and for converting qcow2 to qcow2 can use use the
source size.

The most interesting case is converting raw to qcow2, and we want to test:
- empty file
- file with some clusters allocated
- file with all clusters allocated


> +done
> +
> +# success, all done
> +echo "*** done"
> +rm -f $seq.full
> +status=0
> diff --git a/tests/qemu-iotests/178.out.qcow2
> b/tests/qemu-iotests/178.out.qcow2
> new file mode 100644
> index 000..3fe3f5f
> --- /dev/null
> +++ b/tests/qemu-iotests/178.out.qcow2
> @@ -0,0 +1,33 @@
> +QA output created by 178
> +Input validation
> +
> +Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
> +qemu-img: Either --size N or one filename must be specified.
> +qemu-img: --size N cannot be used together with a filename.
> +qemu-img: At most one filename argument is allowed.
> +qemu-img: --object, --image-opts, -f, and -l require a filename argument.
> +qemu-img: --object, --image-opts, -f, and -l require a filename argument.
> +qemu-img: --object, --image-opts, -f, and -l require a filename argument.
> +qemu-img: --object, --image-opts, -f, and -l require a filename argument.
> +qemu-img: Invalid option list: ,
> +qemu-img: Invalid parameter 'snapshot.foo'
> +qemu-img: Failed in parsing snapshot param 'snapshot.foo'
> +qemu-img: --output must be used with human or json as argument.
> +qemu-img: Image size must be less than 8 EiB!
> +qemu-img: Unknown file format 'foo'
> +
> +Size calculation
> +
> +required bytes: 589824
> +fully allocated bytes: 2148073472 <(214)%20807-3472>
> +required bytes: 327680
> +fully allocated bytes: 1074069504
> +{
> +"required-bytes": 589824,
> +"fully-allocated-bytes": 2148073472 <(214)%20807-3472>
> +}
> +{
> +"required-bytes": 327680,
> +"fully-allocated-bytes": 1074069504
> +}
> 

[Qemu-devel] Strange behaviour in network device initialization.

[Marc Bommert]

Hello development,

I ran into some behaviour I don't understand and which may be a qemu problem 
but which may also be my fault, since I haven't investigated much on QOM so far.
I am currently writing a NIC sysbus device based on the structure of 
hw/net/smc91c111.c

qemu is invoked as:

  $ qemu-system-arm -M mymachine -m 8 -kernel kernel.elf -nographic -net 
nic,id=myid -netdev tap,ifname=tap0,id=myid,script=no,downscript=no -device 
mydevice,netdev=myid


The initialization structure is a little special here. A "legacy helper" 
initialization function is called from the board module mymachine.c:

   for(n = 0; n < nb_nics; n++) {
nd = &nd_table[n];

if (!nd->model || strcmp(nd->model, "mydevice") == 0) {
mydevice_init(nd, MYDEVICE_BASE, pic[17]);
break;
} else {
/* We don't know this NIC model */
}
}

The init function is provided by the device module mydevice.c:

/* Legacy helper function.  Should go away when machine config files are 
implemented.  */
void mydevice_init(NICInfo *nd, uint32_t base, qemu_irq irq)
{
DeviceState *dev;
SysBusDevice *s;

qemu_check_nic_model(nd, "mydevice");
dev = qdev_create(NULL, TYPE_MYDEVICE);
s = SYS_BUS_DEVICE(dev);
mydevice_state *state = MY_DEVICE(dev);

qdev_set_nic_properties(dev, nd);
qdev_init_nofail(dev);
sysbus_mmio_map(s, 0, base);
sysbus_connect_irq(s, 0, irq);
}

and the actual class/instance initializers are:

static int mydevice_init1(Object *obj)
{
DeviceState *dev = DEVICE(obj);
mydevice_state *s = MY_DEVICE(dev);
SysBusDevice *sbd = SYS_BUS_DEVICE(obj);

memory_region_init_io(&s->mmio, OBJECT(s), &mydevice_mem_ops, s,
"mydevice-mmio", 0x4);
sysbus_init_mmio(sbd, &s->mmio);
sysbus_init_irq(sbd, &s->irq);

qemu_macaddr_default_if_unset(&s->conf.macaddr);
s->nic = qemu_new_nic(&net_mydevice_info, &s->conf,
object_get_typename(OBJECT(dev)), dev->id, s);
qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
mydevice_reset(s);
return 0;
}

static void mydevice_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);

k->init = mydevice_init1;
dc->reset = mydevice_reset;
dc->vmsd = &vmstate_mydevice;
dc->props = mydevice_properties;
}

static const TypeInfo mydevice_info = {
.name  = TYPE_MYDEVICE,
.parent= TYPE_SYS_BUS_DEVICE,
.instance_size = sizeof(mydevice_state),
.class_init= mydevice_class_init,
};


Now, the actual problem is that mydevice_init1() is called twice and the device 
state is also instantiated twice. Thus, s->irq is initialized twice, but only 
the first one gets connected. During runtime, the second state instance is 
passed with a NULL s->irq in the device state to the memops. The IRQ never 
fires.

Here are the stack traces of the both initialization calls:

#0  mydevice_init1 (obj=0x573bb010) at 
/home/brightwise/qemu-2.8.0/hw/mymachine/mydevice.c:700
#1  0x55a020f5 in sysbus_device_init (dev=0x573bb010) at 
hw/core/sysbus.c:211
#2  0x559fae58 in device_realize (dev=0x573bb010, 
errp=0x7fffdbd0) at hw/core/qdev.c:213
#3  0x559fc96f in device_set_realized (obj=0x573bb010, value=true, 
errp=0x7fffdd70) at hw/core/qdev.c:918
#4  0x55bd733c in property_set_bool (obj=0x573bb010, 
v=0x573bdb20, name=0x560bd162 "realized", opaque=0x5738eca0, 
errp=0x7fffdd70) at qom/object.c:1854
#5  0x55bd5847 in object_property_set (obj=0x573bb010, 
v=0x573bdb20, name=0x560bd162 "realized", errp=0x7fffdd70) at 
qom/object.c:1088
#6  0x55bd866f in object_property_set_qobject (obj=0x573bb010, 
value=0x573bda90, name=0x560bd162 "realized", errp=0x7fffdd70) at 
qom/qom-qobject.c:27
#7  0x55bd5aea in object_property_set_bool (obj=0x573bbst ask on 
the mailing list for someone else to do it on your behalf (self-creation is 
prohibited to cut down on spam accounts).
Start with reading the QEMU wiki.
Contribute to the QEMU wiki by adding new topics or im010, value=true, 
name=0x560bd162 "realized", errp=0x7fffdd70) at qom/object.c:1157
#8  0x559fb423 in qdev_init_nofail (dev=0x573bb010) at 
hw/core/qdev.c:358
#9  0x5585705e in mydevice_init (nd=0x56b40280 , 
base=1310720, irq=0x57334550) at 
/home/brightwise/qemu-2.8.0/hw/mymachine/mydevice.c:776
#10 0x5585459a in mymachine_init (machine=0x57038dc0, board_id=256) 
at /home/brightwise/qemu-2.8.0/hw/mymachine/mymachine.c:341
#11 0x558546ad in _machin

Re: [Qemu-devel] Strange behaviour in network device initialization.

[Peter Maydell]

On 18 March 2017 at 21:15, Marc Bommert  wrote:
> I ran into some behaviour I don't understand and which may be a qemu problem 
> but which may also be my fault, since I haven't investigated much on QOM so 
> far.
> I am currently writing a NIC sysbus device based on the structure of 
> hw/net/smc91c111.c
>
> qemu is invoked as:
>
>   $ qemu-system-arm -M mymachine -m 8 -kernel kernel.elf -nographic -net 
> nic,id=myid -netdev tap,ifname=tap0,id=myid,script=no,downscript=no -device 
> mydevice,netdev=myid
>
>
> The initialization structure is a little special here. A "legacy helper" 
> initialization function is called from the board module mymachine.c:
>
>for(n = 0; n < nb_nics; n++) {
> nd = &nd_table[n];
>
> if (!nd->model || strcmp(nd->model, "mydevice") == 0) {
> mydevice_init(nd, MYDEVICE_BASE, pic[17]);
> break;
> } else {
> /* We don't know this NIC model */
> }
> }


> Now, the actual problem is that mydevice_init1() is called twice and
> the device state is also instantiated twice.

This is expected, because you're creating two devices.
Device 1 is the one that's created by calling
mydevice_init() here in the board code.
Device 2 is created because you say "-device mydevice"
on the command line.

smc91c111 is an "embedded" device which is memory mapped
into a particular address in the memory space and directly
wired up to an interrupt line. (QEMU calls these "sysbus
devices".) These can't be sensibly created from the command
line because there's no way to specify how to wire them
up and where they live in memory.

Conversely, the -device command line option is for
devices which go in pluggable buses, like PCI and
ISA devices. The -device option says "create one
of these and plug it into some available bus of
the right type"; it creates devices in addition to
any that the board creates itself.

The slightly odd thing is that -device mydevice
doesn't fail for you -- if you try that for smc91c111 it
will complain:
 "Device smc91c111 cannot be dynamically instantiated"
to let you know that the command line option is wrong.

PS: smc91c111 is not a very good model to copy,
because that device code is very old, and doesn't
necessarily follow current QEMU coding practices.
Looking at a device that's been added to QEMU
more recently may be a better idea.

thanks
-- PMM

[Qemu-devel] [Bug 747583] Re: Windows 2008 Time Zone Change Even When Using -locatime

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Windows 2008 Time Zone Change Even When Using -locatime

Status in QEMU:
  Expired

Bug description:
  * What cpu model : Intel(R) Xeon(R) CPU E5620  @ 2.40GHz
  * What kvm version you are using. : qemu-kvm-0.12.3
  * The host kernel version : 2.6.32-30-server
  * What host kernel arch you are using (i386 or x86_64) : x86_64
  * What guest you are using, including OS type: Windows 2008 Enterprise x86_64
  * The qemu command line you are using to start the guest : /usr/bin/kvm -S -M 
pc-0.12 -enable-kvm -m 1024 -smp 1 -name 2-6176 -uuid 
4d1d56b1-d0b7-506b-31a5-a87c8cb0560b -chardev 
socket,id=monitor,path=/var/lib/libvirt/qemu/2-6176.monitor,server,nowait 
-monitor chardev:monitor -localtime -boot c -drive 
file=/dev/disk/by-id/scsi-3600144f05c1109004d9602950073,if=virtio,index=0,boot=on,format=raw
 -drive 
file=/dev/disk/by-id/scsi-3600144f0eae881004c7bb0920037,if=ide,media=cdrom,index=2,format=raw
 -net nic,macaddr=00:00:d1:d0:3f:5e,vlan=0,name=nic.1 -net 
tap,fd=212,vlan=0,name=tap.1 -net 
nic,macaddr=00:00:0a:d0:3f:5e,vlan=1,name=nic.1 -net 
tap,fd=213,vlan=1,name=tap.1 -chardev pty,id=serial0 -serial chardev:serial0 
-parallel none -usb -usbdevice tablet -vnc 0.0.0.0:394,password -k en-us -vga 
cirrus
  * Whether the problem goes away if using the -no-kvm-irqchip or -no-kvm-pit 
switch. : Unable to test
  * Whether the problem also appears with the -no-kvm switch. : Unable to test

  Host time zone: EDT Guest time zone: PDT

  Steps to reproduce:
  1) Set time zone to (GMT-08:00) Pacific Time (US & Canada) on guest
  2) Power off Windows 2008 Enterprise x86_64 guest completely. Ensure the kvm 
process exits.
  3) Power on Windows 2008 Enterprise x86_64 guest using virsh start 
  4) Server will show EDT time but have the time zone still set to (GMT-08:00) 
Pacific Time (US & Canada).

  Syncing the time after stopping and starting the kvm process using
  Windows "Internet Time" ntp time sync will sync the time to the
  correct PDT time.

  Doing a reboot from within the guest's operating system where kvm does
  not exit will not cause the timezone shift to happen.

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

[Qemu-devel] [Bug 638806] Re: Crashes with kfreebsd guest when using KVM

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Crashes with kfreebsd guest when using KVM

Status in QEMU:
  Expired

Bug description:
  commit 46411f863c26ff85c48b97939502007610c95398

  Linux host
  Kfreebsd guest
  qemu -boot c -hda qemu_kfreebsd_i386.img -enable-kvm

  QEMU crashes with free on invalid pointer:

  *** glibc detected *** qemu: free(): invalid pointer: 0x0253cf60 ***
  === Backtrace: =
  /lib/libc.so.6(+0x71ad6)[0x7f0844fa5ad6]
  qemu[0x494283]
  qemu[0x4951ca]
  qemu[0x49aa01]
  qemu[0x495d15]
  qemu[0x5197f4]
  qemu[0x51a297]
  /lib/libc.so.6(__libc_start_main+0xfd)[0x7f0844f52c4d]
  qemu[0x408799]
  === Memory map: 
  0040-00625000 r-xp  08:06 4186599
/usr/local/bin/qemu
  00825000-00847000 rw-p 00225000 08:06 4186599
/usr/local/bin/qemu
  00847000-00fed000 rw-p  00:00 0 
  00fed000-00fee000 rwxp  00:00 0 
  00fee000-0104b000 rw-p  00:00 0 
  022fe000-023ff000 rw-p  00:00 0 
  023ff000-0240f000 rw-p  00:00 0 
  0240f000-0255d000 rw-p  00:00 0 
  41cd2000-43cd2000 rwxp  00:00 0 
  7f0835c22000-7f0835c38000 r-xp  08:06 3407959
/lib/libgcc_s.so.1
  7f0835c38000-7f0835e37000 ---p 00016000 08:06 3407959
/lib/libgcc_s.so.1
  7f0835e37000-7f0835e38000 rw-p 00015000 08:06 3407959
/lib/libgcc_s.so.1
  7f0835e38000-7f0835e3d000 r-xp  08:06 4185228
/usr/lib/libXfixes.so.3.1.0
  7f0835e3d000-7f083603c000 ---p 5000 08:06 4185228
/usr/lib/libXfixes.so.3.1.0
  7f083603c000-7f083603d000 rw-p 4000 08:06 4185228
/usr/lib/libXfixes.so.3.1.0
  7f083603d000-7f0836046000 r-xp  08:06 4178659
/usr/lib/libXcursor.so.1.0.2
  7f0836046000-7f0836246000 ---p 9000 08:06 4178659
/usr/lib/libXcursor.so.1.0.2
  7f0836246000-7f0836247000 rw-p 9000 08:06 4178659
/usr/lib/libXcursor.so.1.0.2
  7f0836247000-7f0836294000 rw-p  00:00 0 
  7f083631c000-7f0836491000 r--p  08:06 3670017
/usr/lib/locale/locale-archive
  7f0836491000-7f0836499000 r-xp  08:06 516333 
/usr/lib/libXrandr.so.2.2.0
  7f0836499000-7f0836698000 ---p 8000 08:06 516333 
/usr/lib/libXrandr.so.2.2.0
  7f0836698000-7f0836699000 rw-p 7000 08:06 516333 
/usr/lib/libXrandr.so.2.2.0
  7f0836699000-7f08366a2000 r-xp  08:06 4180666
/usr/lib/libXrender.so.1.3.0
  7f08366a2000-7f08368a2000 ---p 9000 08:06 4180666
/usr/lib/libXrender.so.1.3.0
  7f08368a2000-7f08368a3000 rw-p 9000 08:06 4180666
/usr/lib/libXrender.so.1.3.0
  7f08368a3000-7f08368b4000 r-xp  08:06 4181769
/usr/lib/libXext.so.6.4.0
  7f08368b4000-7f0836ab4000 ---p 00011000 08:06 4181769
/usr/lib/libXext.so.6.4.0
  7f0836ab4000-7f0836ab5000 rw-p 00011000 08:06 4181769
/usr/lib/libXext.so.6.4.0
  7f0836ad6000-7f0836ad7000 ---p  00:00 0 
  7f0836ad7000-7f0836f5b000 rw-p  00:00 0 
  7f0836f6e000-7f0837088000 rw-s  00:04 1900557
/SYSV (deleted)
  7f0837088000-7f0837089000 rw-p  00:00 0 
  7f0837089000-7f0837889000 rw-p  00:00 0 
  7f0837889000-7f083788b000 rw-p  00:00 0 
  7f083788b000-7f083f88b000 rw-p  00:00 0 
  7f083f88b000-7f083f88c000 rw-p  00:00 0 
  7f083f88c000-7f083f88d000 ---p  00:00 0 
  7f083f88d000-7f0841a8f000 rw-p  00:00 0 
  7f0841a8f000-7f0841a94000 r-xp  08:06 4183916
/usr/lib/libXdmcp.so.6.0.0
  7f0841a94000-7f0841c93000 ---p 5000 08:06 4183916
/usr/lib/libXdmcp.so.6.0.0
  7f0841c93000-7f0841c94000 rw-p 4000 08:06 4183916
/usr/lib/libXdmcp.so.6.0.0
  7f0841c94000-7f0841c96000 r-xp  08:06 4183879
/usr/lib/libXau.so.6.0.0
  7f0841c96000-7f0841e96000 ---p 2000 08:06 4183879
/usr/lib/libXau.so.6.0.0
  7f0841e96000-7f0841e97000 rw-p 2000 08:06 4183879
/usr/lib/libXau.so.6.0.0
  7f0841e97000-7f0841eb6000 r-xp  08:06 3407929
/lib/libx86.so.1
  7f0841eb6000-7f08420b6000 ---p 0001f000 08:06 3407929
/lib/libx86.so.1
  7f08420b6000-7f08420b8000 rw-p 0001f000 08:06 3407929
/lib/libx86.so.1
  7f08420b8000-7f08420b9000 rw-p  00:00 0 
  7f08420b9000-7f08420bc000 r-xp  08:06 4181768
/usr/lib

[Qemu-devel] [Bug 678363] Re: Swapping caps lock and control causes qemu confusion

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  Swapping caps lock and control causes qemu confusion

Status in QEMU:
  Expired

Bug description:
  Running Fedora14 [host], I have caps-lock and control swapped over in
  my keyboard preferences.

  Qemu doesn't cope very well with this; running an OS inside Qemu
  (again fedora, suspect that it doesn't matter):

  The physical caps-lock key [which the host uses as control] toggles
  caps-lock on both press and release.

  The physical control key [which the host uses as caps-lock], acts as
  both a caps-lock and control key.

  Qemu should either respect my keyboard layout or else ignore it
  completely.

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

[Qemu-devel] [Bug 772358] Re: VNC working depends on command line options order

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  VNC working depends on command line options order

Status in QEMU:
  Expired

Bug description:
  OS: Ubuntu 10.04.2, amd64
  Pkg version: 0.12.3+noroms-0ubuntu9.5

  if -nographic option is specified before -vnc, vnc works, if vice-
  versa, it does not. I have been told (thanks, mjt), that -nographic is
  supposed to disable any graphic output, including vnc, so possibly
  it's a documentation bug:

  - kvm man page talks about -nographic disabling SDL , not VNC. While
  it might be the same to you, it was not to me and my colleagues

  - if -vnc and -nographic are conflicting, perhaps kvm should error out
  or at least warn

  - monitor console's message on "change vnc 127.0.0.1:1" command:
  "Could not start server on 127.0.0.1:1" is not helpful either

  - order of the options should not matter

  Example: (VNC works)

  /usr/bin/kvm -name ubuntu.example.com -m 3076 -smp 2 -drive
  if=virtio,file=/dev/vg0/kvm-
  ubuntu,boot=on,media=disk,cache=none,index=0 -net
  nic,vlan=0,model=virtio,macaddr=00:03:03:03:03:01 -net
  tap,ifname=kvm_ubuntu,vlan=0,script=no,downscript=no -balloon virtio
  -nographic -daemonize -vnc 127.0.0.1:1 -pidfile /var/run/kvm/1

  Example: (VNC does not work, also confuses terminal):

  /usr/bin/kvm -name ubuntu.example.com -m 3076 -smp 2 -drive
  if=virtio,file=/dev/vg0/kvm-
  ubuntu,boot=on,media=disk,cache=none,index=0 -net
  nic,vlan=0,model=virtio,macaddr=00:03:03:03:03:01 -net
  tap,ifname=kvm_ubuntu,vlan=0,script=no,downscript=no -balloon virtio
  -vnc 127.0.0.1:1 -nographic -daemonize -pidfile /var/run/kvm/1

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

[Qemu-devel] [Bug 784977] Re: qemu-img convert fails to convert, generates a 512byte file output

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  qemu-img convert fails to convert, generates a 512byte file output

Status in QEMU:
  Expired

Bug description:
  I have a Vmware image, so I have files like 'Ubuntu.vmdk', want to
  convert to VirtualBox .vdi format using qemu, the first stage of
  extracting the image with 'qemu-img convert Ubuntu.vmdk output.bin'
  just generates a 512byte file:

  {quote}
  # Disk DescriptorFile
  version=1
  CID=36be9761
  parentCID=
  createType="twoGbMaxExtentSparse"

  # Extent description
  RW 4192256 SPARSE "Ubuntu-s001.vmdk"
  RW 4192256 SPARSE "Ubuntu-s002.vmdk"
  RW 4192256 SPARSE "Ubuntu-s003.vmdk"
  RW 4192256 SPARSE "Ubuntu-s004.vmdk"
  RW 4192256 SPARSE "Ubuntu-s005.vmdk"
  RW 4192256 SPARSE "Ubuntu-s006.vmdk"
  RW 4192256 SPARSE "Ubuntu-s007.vmdk"
  RW 4192256 SPARSE "Ubuntu-s008.vmdk"
  RW 4192256 SPARSE "Ubuntu-s009.vmdk"
  RW 4192256 SPARSE "Ubuntu-s010.vmdk"
  RW 20480 SPARSE "Ubunt
  {quote}

  Here is the input Ubuntu.vmdk file:
  {quote}
  # Disk DescriptorFile
  version=1
  CID=36be9761
  parentCID=
  createType="twoGbMaxExtentSparse"

  # Extent description
  RW 4192256 SPARSE "Ubuntu-s001.vmdk"
  RW 4192256 SPARSE "Ubuntu-s002.vmdk"
  RW 4192256 SPARSE "Ubuntu-s003.vmdk"
  RW 4192256 SPARSE "Ubuntu-s004.vmdk"
  RW 4192256 SPARSE "Ubuntu-s005.vmdk"
  RW 4192256 SPARSE "Ubuntu-s006.vmdk"
  RW 4192256 SPARSE "Ubuntu-s007.vmdk"
  RW 4192256 SPARSE "Ubuntu-s008.vmdk"
  RW 4192256 SPARSE "Ubuntu-s009.vmdk"
  RW 4192256 SPARSE "Ubuntu-s010.vmdk"
  RW 20480 SPARSE "Ubuntu-s011.vmdk"

  # The Disk Data Base 
  #DDB

  ddb.toolsVersion = "7240"
  ddb.adapterType = "lsilogic"
  ddb.geometry.sectors = "63"
  ddb.geometry.heads = "255"
  ddb.geometry.cylinders = "2610"
  ddb.virtualHWVersion = "6"
  {quote}

  No stack trace or other output was found.  Anything I can add (other
  than the 20G VM image to reproduce and I'll be happy to provide)

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

[Qemu-devel] GSOC Qemu Project

[aahud]

Hello my name is Aaron Hudson,

I am sending this email, admittedly late, to suggest a new project. I 
would love to see Qemu ported to an operating system without a 
monolithic kernel. My initial ideas for target platforms are Minix3 or a 
Plan9-like (ie Harvey or 9front). My personal preference would be 
Harvey, as I have made small contributions to that project, and am 
simply more familiar.


Another goal might be to look into hypervisors designed for microkernels 
(NOVA, Fiasco.OC, OKL4, etc), and making sure that the userspace 
solution is flexible enough to support those implementations. Regardless 
of whether or not the summer project would include that as a goal.


If you would like more detail or simply like to talk about the idea, I'd 
love to communicate via email, or IRC.


Thank you,

Aaron Hudson

Senior @ New Mexico Institute of Mining and Technology
Computer Science Major
System Administrator for Computer Science Department

[Qemu-devel] [Bug 1674056] [NEW] USB keyboard and mouse sucked into qemu-kvm (somewhere)

[spongebob]

Public bug reported:

i am unable to run a command line qemu that does not "suck in" the keyboard and 
mouse of the host PC
i tried all that i could from the command line parameters i want to run a 
headless gui-less kvm host

if i specify a second set of keyboard and mouse with the -usb the only thing 
that is diffrent is that i have a keyboard and mouse in the VM if i specify the 
host keyboard and mouse same thing ... the vm is working fine but the host has 
no control , no keyboard. i dont see any output of anything 
the only recourse i have is ctrl+alt+delete  and that resets the host after 2-3 
times. 

i tried ctrl+alt, ctrl+alt+x , c , z , 2 , etc... also alt + all those 
combination and alt with F keys 
no luck. 


my command line looks like this (altough i tried many other variations)
 
qemu-system-x86_64 -M q35 -enable-kvm \
-cpu host,kvm=off -m 4096 -smp cpu=4,sockets=1,cores=4,treads=1 \
-drive file=xyz.qcow2,if=scsi \
-device vfio-pci, ... (GPU) \
-device vfio-pci,  (GPU audio) \
-usb -usbdevice host:: -usbdevice host:: \   <<< same behaviour 
with and without
-vga none -vnc localhost:1 -daemonize  

i tried with -nographics , -curses, -monitor stdio, pty and none, same result 
and with -serial as well
tried  8Gb
keyboard is logitech
mouse is logitech

distro is suse leap 42.1 (made with suseStudio)

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  USB keyboard and mouse sucked into qemu-kvm (somewhere)

Status in QEMU:
  New

Bug description:
  i am unable to run a command line qemu that does not "suck in" the keyboard 
and mouse of the host PC
  i tried all that i could from the command line parameters i want to run a 
headless gui-less kvm host

  if i specify a second set of keyboard and mouse with the -usb the only thing 
that is diffrent is that i have a keyboard and mouse in the VM if i specify the 
host keyboard and mouse same thing ... the vm is working fine but the host has 
no control , no keyboard. i dont see any output of anything 
  the only recourse i have is ctrl+alt+delete  and that resets the host after 
2-3 times. 

  i tried ctrl+alt, ctrl+alt+x , c , z , 2 , etc... also alt + all those 
combination and alt with F keys 
  no luck. 

  
  my command line looks like this (altough i tried many other variations)
   
  qemu-system-x86_64 -M q35 -enable-kvm \
  -cpu host,kvm=off -m 4096 -smp cpu=4,sockets=1,cores=4,treads=1 \
  -drive file=xyz.qcow2,if=scsi \
  -device vfio-pci, ... (GPU) \
  -device vfio-pci,  (GPU audio) \
  -usb -usbdevice host:: -usbdevice host:: \   <<< same 
behaviour with and without
  -vga none -vnc localhost:1 -daemonize  

  i tried with -nographics , -curses, -monitor stdio, pty and none, same result 
and with -serial as well
  tried  8Gb
  keyboard is logitech
  mouse is logitech

  distro is suse leap 42.1 (made with suseStudio)

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