date:20181104

Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState

2018-11-04 Thread Gerd Hoffmann

On Wed, Oct 31, 2018 at 03:06:04PM -0300, Eduardo Habkost wrote:
> On Wed, Oct 31, 2018 at 12:04:16PM -0400, John Snow wrote:
> > 
> > 
> > On 10/30/2018 09:32 AM, Philippe Mathieu-Daudé wrote:
> > > Hi Gerd,
> > > 
> > > On 30/10/18 12:13, Gerd Hoffmann wrote:
> > >> Indicates support state for somerhing (device, backend, subsystem, ...)
> > > 
> > > "something"
> > > 
> > >> in qemu.  Modeled roughly after the "S:" states we have in MAINTANERS.
> > >>
> > >> Signed-off-by: Gerd Hoffmann 
> > >> ---
> > >>   include/qemu/support-state.h | 17 +
> > >>   util/support-state.c | 23 +++
> > >>   qapi/common.json | 16 
> > >>   util/Makefile.objs   |  1 +
> > >>   4 files changed, 57 insertions(+)
> > >>   create mode 100644 include/qemu/support-state.h
> > >>   create mode 100644 util/support-state.c
> > >>
> > >> diff --git a/include/qemu/support-state.h b/include/qemu/support-state.h
> > >> new file mode 100644
> > >> index 00..5fd3c83eee
> > >> --- /dev/null
> > >> +++ b/include/qemu/support-state.h
> > >> @@ -0,0 +1,17 @@
> > >> +#ifndef QEMU_SUPPORT_STATE_H
> > >> +#define QEMU_SUPPORT_STATE_H
> > >> +
> > >> +#include "qapi/qapi-types-common.h"
> > >> +
> > >> +typedef struct QemuSupportState {
> > >> +    SupportState state;
> > >> +    const char *reason;
> > >> +} QemuSupportState;
> > >> +
> > >> +void qemu_warn_support_state(const char *type, const char *name,
> > >> + QemuSupportState *state);
> > >> +
> > >> +bool qemu_is_deprecated(QemuSupportState *state);
> > >> +bool qemu_is_obsolete(QemuSupportState *state);
> > >> +
> > >> +#endif /* QEMU_SUPPORT_STATE_H */
> > >> diff --git a/util/support-state.c b/util/support-state.c
> > >> new file mode 100644
> > >> index 00..7966fa0fc7
> > >> --- /dev/null
> > >> +++ b/util/support-state.c
> > >> @@ -0,0 +1,23 @@
> > >> +#include "qemu/osdep.h"
> > >> +#include "qemu/error-report.h"
> > >> +#include "qemu/support-state.h"
> > >> +
> > >> +void qemu_warn_support_state(const char *type, const char *name,
> > >> + QemuSupportState *state)
> > >> +{
> > >> +    warn_report("%s %s is %s%s%s%s", type, name,
> > >> +    SupportState_str(state->state),
> > >> +    state->reason ? " ("  : "",
> > >> +    state->reason ? state->reason : "",
> > >> +    state->reason ? ")"   : "");
> > >> +}
> > >> +
> > >> +bool qemu_is_deprecated(QemuSupportState *state)
> > >> +{
> > >> +    return state->state == SUPPORT_STATE_DEPRECATED;
> > >> +}
> > >> +
> > >> +bool qemu_is_obsolete(QemuSupportState *state)
> > >> +{
> > >> +    return state->state == SUPPORT_STATE_OBSOLETE;
> > >> +}
> > >> diff --git a/qapi/common.json b/qapi/common.json
> > >> index 021174f04e..78176151af 100644
> > >> --- a/qapi/common.json
> > >> +++ b/qapi/common.json
> > >> @@ -151,3 +151,19 @@
> > >>    'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
> > >>    'sh4eb', 'sparc', 'sparc64', 'tricore', 'unicore32',
> > >>    'x86_64', 'xtensa', 'xtensaeb' ] }
> > >> +
> > >> +##
> > >> +# @SupportState:
> > >> +#
> > >> +# Indicate Support level of qemu devices, backends, subsystems, ...
> > >> +#
> > >> +# Since: 3.2
> > >> +##
> > >> +{ 'enum': 'SupportState',
> > >> +  'data': [ 'unknown',
> > > 
> > > 'unknown' is scary and should be fixed.
> > > 
> > >> +    'supported',
> > >> +    'maintained',
> > >> +    'odd-fixes',
> > > 
> > > All those fit in 'supported'
> > > 
> > >> +    'orphan',
> > >> +    'obsolete',
> > >> +    'deprecated' ] }
> > > 
> > > And all those should appear as 'deprecated' IMHO.
> > > 
> > 
> > You've covered it a bit below, but I think we need more than "supported"
> > and "deprecated" -- at *least* a third state "unsupported" is required, IMO:
> > 
> > - Supported: We expect this to work. We test this component. We will
> > ship CVE fixes in a timely manner for this component. You are, as a
> > user, using something that is cared for and you may rely on us to care
> > for it.

supported + maintained.  Yes, merging them makes sense probably.

> > - Unsupported: We expect this to work, but nobody is tending to it
> > actively. It might be perfectly OK, but the tests and support may be
> > lacking. Try not to rely on this in an enterprise environment unless you
> > have resources to devote to caring for it personally. I'd count things
> > like Raspberry Pi boards in this category: they work, usually, but not
> > fully. Some people are working on them, but they're not ready for prime
> > time usage.
> 
> I wonder: do we need a distinction between code that's
> unsupported and expected to be removed in the next versions of
> QEMU, and code that's unsupported but not planned to be removed
> yet?

odd-fixes + orphan would be the "not planned to be removed" bucket.
Maybe merge

Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState

2018-11-04 Thread Gerd Hoffmann

  Hi,

> > - Maintainers can deprecate stuffs
> > - Orphan code can become Supported
> > - Once scheduled for removal, there is no way back
> > - 'Unknown' seems pretty similar to 'Orphan'.
> 
> I'm still worried that the supported/unsupported distinction may
> cause unnecessary hassle for every downstream distributor of
> QEMU.  Do we really have a need to differentiate supported vs
> unsupported device types at runtime?

How do you suggest to handle cirrus then?

Trying to deprecate it outright didn't work very well, kind of
understandable given that it has been the default for a long time.

So I think we have to mark cirrus as "obsolete", printing a message for
the users that they should switch to another display device (stdvga for
example), but keep it working for a while.

There are also a bunch of devices where I suspect they are not used much
if at all.  All those isa sound cards for example.  Playing old DOS
games is pretty much the only use case I can think of.  But I'm
wondering whenever people actually use qemu for that.  There are
alternatives which probably handle that use case better, i.e. dosbox.

Simliar case is bluetooth emulation.  I can't remember having seen any
message or patch for years.

Tagging such devices as "obsolete", with a message asking people to
report their use cases, might help figuring if and why those devices are
used in the wild.

> I'd prefer to make support/unsupported differentiation to be a
> build system feature (e.g. a CONFIG_UNSUPPORTED build-time
> option) instead of a QMP/runtime feature.

That would be nice too, but I think we need kbuild first, otherwise
it'll be pretty messy.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] chardev: fix mess in OPENED/CLOSED events when muxed

2018-11-04 Thread Marc-André Lureau

Hi
On Mon, Nov 5, 2018 at 11:22 AM Artem Pisarenko
 wrote:
>
> Sorry, I forgot to check unit tests. Although, it's very strange that this 
> specific test failed while things work functionally...
>
> > I am a bit reluctant to take patches that don't actually "fix" things.
> >
> > Could you add some tests to demonstrate the problems?
>
> Ok
>
> >> @@ -257,6 +257,7 @@ void qemu_chr_fe_set_handlers(CharBackend *b,
> >>  {
> >>  Chardev *s;
> >>  int fe_open;
> >> +static __thread bool mux_reentered;
> >
> > Not very elegant. Maybe mux_chr_set_handlers() could call a refactored
> > internal chr_fe_set_handlers() with an extra arg "no_open_event" ?
>
> Agree. It would make this hack more elegant. Although, it may become 
> irrelevant as soon as I'll find soultion for failed docker test...
>
> >> @@ -272,21 +272,24 @@ static void char_mux_finalize(Object *obj)
> >>  for (i = 0; i < d->mux_cnt; i++) {
> >>  CharBackend *be = d->backends[i];
> >>  if (be) {
> >> +if (be->chr && be->chr->be_open) {
> >> +qemu_chr_be_event(be->chr, CHR_EVENT_CLOSED);
> >> +}
> >
> > It looks like this could be a seperate patch, with a seperate test.
>
> Why this should be separate ? Do you mean that overall "opened/closed" 
> pairing fix should be separated to "opened" fix+test and "closed" fix+test ?
>
> Since in next version it cannot be single patch anymore, how should I proceed 
> with it ? Should I publish it as patch series with same subject marked as V2 
> or start new patch series?

A patch series would be great. You can keep the subject and make it v2.

thanks

Re: [Qemu-devel] [PATCH 4/4] MAINTAINERS: s390/boot: the ipl code and the bios belong together

2018-11-04 Thread Thomas Huth

On 2018-10-29 16:42, Christian Borntraeger wrote:
> The s390-ccw bios and the ipl code do work in lock-step. Let us merge
> them in the maintainer file.
> 
> Signed-off-by: Christian Borntraeger 
> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e63cfa2..8ce223d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -946,10 +946,11 @@ T: git git://github.com/cohuck/qemu.git s390-next
>  T: git git://github.com/borntraeger/qemu.git s390-next
>  L: qemu-s3...@nongnu.org
>  
> -S390-ccw Bios
> +S390-ccw boot
>  M: Christian Borntraeger 
>  M: Thomas Huth 
>  S: Supported
> +F: hw/s390x/ipl.*
>  F: pc-bios/s390-ccw/
>  F: pc-bios/s390-ccw.img
>  T: git git://github.com/borntraeger/qemu.git s390-next
> 

Acked-by: Thomas Huth

Re: [Qemu-devel] [PATCH] chardev: fix mess in OPENED/CLOSED events when muxed

2018-11-04 Thread Artem Pisarenko

Sorry, I forgot to check unit tests. Although, it's very strange that this
specific test failed while things work functionally...

> I am a bit reluctant to take patches that don't actually "fix" things.
>
> Could you add some tests to demonstrate the problems?

Ok

>> @@ -257,6 +257,7 @@ void qemu_chr_fe_set_handlers(CharBackend *b,
>>  {
>>  Chardev *s;
>>  int fe_open;
>> +static __thread bool mux_reentered;
>
> Not very elegant. Maybe mux_chr_set_handlers() could call a refactored
> internal chr_fe_set_handlers() with an extra arg "no_open_event" ?

Agree. It would make this hack more elegant. Although, it may become
irrelevant as soon as I'll find soultion for failed docker test...

>> @@ -272,21 +272,24 @@ static void char_mux_finalize(Object *obj)
>>  for (i = 0; i < d->mux_cnt; i++) {
>>  CharBackend *be = d->backends[i];
>>  if (be) {
>> +if (be->chr && be->chr->be_open) {
>> +qemu_chr_be_event(be->chr, CHR_EVENT_CLOSED);
>> +}
>
> It looks like this could be a seperate patch, with a seperate test.

Why this should be separate ? Do you mean that overall "opened/closed"
pairing fix should be separated to "opened" fix+test and "closed" fix+test ?

Since in next version it cannot be single patch anymore, how should I
proceed with it ? Should I publish it as patch series with same subject
marked as V2 or start new patch series?

Re: [Qemu-devel] [PATCH v3 7/8] target-alpha: use HTTPS git URL for palcode

2018-11-04 Thread Richard Henderson

On 11/4/18 11:24 AM, Stefan Hajnoczi wrote:
> When you clone the repository without previous commit history, 'git://'
> doesn't protect from man-in-the-middle attacks.  HTTPS is more secure
> since the client verifies the server certificate.
> 
> Cc: Richard Henderson 
> Suggested-by: Eric Blake 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  pc-bios/README | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Richard Henderson 


r~

Re: [Qemu-devel] [RFC PATCH spice v2 1/2] QXL interface: add functions to identify monitors in the guest

2018-11-04 Thread Gerd Hoffmann

> 2. Have a single function as follows:
> 
> void spice_qxl_set_device_info(QXLInstance *instance,
>const char *device_address,
>uint32_t device_display_id_start,
>uint32_t device_display_id_count);

How about:

void spice_qxl_set_device_info(QXLInstance *instance,
   const char *device_address,
   uint32_t device_display_id);

I don't think we need start+count:

 * For single-head devices device_display_id will be zero.
 * For one-channel-per-head multihead devices (i.e. virtio-gpu)
   device_display_id will enumerate the heads (so everybody can figure
   which channel is which head).
 * For one-channel-per-device multihead devices (i.e. qxl/linux)
   device_display_id will be zero too.  Number of heads is set via
   spice_qxl_set_max_monitors().

cheers,
  Gerd

Re: [Qemu-devel] one issue about usb passsthrough devices

2018-11-04 Thread gerd hoffmann

On Thu, Nov 01, 2018 at 01:57:15AM +, linzhecheng wrote:
> Hi, all
> A found a problem about libusb, the reproducing steps are as followed:
> 1. start up a vm with host-usb devices
> 2. kill -9 `pgrep qemu`
> We can not see the usb device on host any more, I think this is because qemu 
> has no chance to release
> resources to kernel in this case.

Yes.

> How can we recover environment if we encounter this problem?

Unplug device, plug it again?
Use -TERM instead of -KILL, so it doesn't happen in the first place?

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v4 01/13] qtest: Add set_irq_in command to set IRQ/GPIO level

2018-11-04 Thread Thomas Huth

On 2018-11-02 18:07, Steffen Görtz wrote:
> Adds a new qtest command "set_irq_in" which allows
> to set qemu gpio lines to a given level.
> 
> Based on https://lists.gnu.org/archive/html/qemu-devel/2012-12/msg02363.html
> which never got merged.
> 
> Signed-off-by: Steffen Görtz 
> Originally-by: Matthew Ogilvie 
> Reviewed-by: Stefan Hajnoczi 
> ---
>  qtest.c  | 43 +++
>  tests/libqtest.c | 10 ++
>  tests/libqtest.h | 28 
>  3 files changed, 81 insertions(+)
[...]
> diff --git a/tests/libqtest.h b/tests/libqtest.h
> index ed88ff99d5..65bffa9ace 100644
> --- a/tests/libqtest.h
> +++ b/tests/libqtest.h
> @@ -232,6 +232,19 @@ void qtest_irq_intercept_in(QTestState *s, const char 
> *string);
>   */
>  void qtest_irq_intercept_out(QTestState *s, const char *string);
>  
> +/**
> + * qtest_set_irq_in:
> + * @s: QTestState instance to operate on.
> + * @string: QOM path of a device
> + * @name: IRQ name
> + * @irq: IRQ number
> + * @level: IRQ level
> + *
> + * Force given device/irq GPIO-in pin to the given level.
> + */
> +void qtest_set_irq_in(QTestState *s, const char *string, const char *name,
> +  int irq, int level);
> +
>  /**
>   * qtest_outb:
>   * @s: #QTestState instance to operate on.
> @@ -678,6 +691,21 @@ static inline void irq_intercept_out(const char *string)
>  qtest_irq_intercept_out(global_qtest, string);
>  }
>  
> +/**
> + * qtest_set_irq_in:
> + * @string: QOM path of a device
> + * @name: IRQ name
> + * @irq: IRQ number
> + * @level: IRQ level
> + *
> + * Force given device/IRQ GPIO-in pin to the given level.
> + */
> +static inline void set_irq_in(const char *string, const char *name,
> +  int irq, int level)
> +{
> +qtest_set_irq_in(global_qtest, string, name, irq, level);
> +}
> +
>  /**
>   * outb:
>   * @addr: I/O port to write to.
> 

 Hi Steffen,

please don't add any new function wrappers around global_qtest anymore.
We recently already started to get rid of this global variable in a
couple of places (see
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=db57d7a3c284db2315d9 and
preceding commits for example), since it causes trouble in tests that
want to run multiple QEMU instances at once (in migration tests for
example). It would be good to have new code clean for this right from
the start.

 Thanks,
  Thomas

Re: [Qemu-devel] [PATCH RFC v7 0/9] qemu_thread_create: propagate errors to callers to check

2018-11-04 Thread Fei Li


Sorry that somehow forget the "#include "qemu/error-report.h" for
hw/usb/ccid-card-emulated.c

Have a nice day, thanks
Fei

On 11/04/2018 02:09 AM, no-re...@patchew.org wrote:

Hi,

This series failed docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

Type: series
Message-id: 20181101101715.9443-1-...@suse.com
Subject: [Qemu-devel] [PATCH RFC v7 0/9] qemu_thread_create: propagate errors 
to callers to check

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-quick@centos7 SHOW_ENV=1 J=8
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
8239f692a6 qemu_thread_create: propagate the error to callers to handle
f73c91c32a migration: add more error handling for postcopy_ram_enable_notify
6b8c9d0a7b migration: remove unused _err parameter in migrate_set_error
adcb648e2e migration: fix the multifd code when receiving less channels
ce89d9baf9 migration: fix the multifd code when sending less channels
a06e512206 migration: fix some segmentation faults when using multifd
7f516dc786 qemu_thread_join: fix segmentation fault
a6f6f24ff3 qemu_init_vcpu: add a new Error parameter to propagate
b44013aa26 Fix segmentation fault when qemu_signal_init fails

=== OUTPUT BEGIN ===
   BUILD   centos7
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-6f6bzbwa/src'
   GEN 
/var/tmp/patchew-tester-tmp-6f6bzbwa/src/docker-src.2018-11-03-14.07.14.17130/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-6f6bzbwa/src/docker-src.2018-11-03-14.07.14.17130/qemu.tar.vroot'...
done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-6f6bzbwa/src/docker-src.2018-11-03-14.07.14.17130/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out '88f18909db731a627456f26d779445f84e449536'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-6f6bzbwa/src/docker-src.2018-11-03-14.07.14.17130/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'6b3d716e2b6472eb7189d3220552280ef3d832ce'
   COPYRUNNER
 RUN test-quick in qemu:centos7
Packages installed:
SDL-devel-1.2.15-14.el7.x86_64
bison-3.0.4-1.el7.x86_64
bzip2-1.0.6-13.el7.x86_64
bzip2-devel-1.0.6-13.el7.x86_64
ccache-3.3.4-1.el7.x86_64
csnappy-devel-0-6.20150729gitd7bc683.el7.x86_64
flex-2.5.37-3.el7.x86_64
gcc-4.8.5-28.el7_5.1.x86_64
gettext-0.19.8.1-2.el7.x86_64
git-1.8.3.1-14.el7_5.x86_64
glib2-devel-2.54.2-2.el7.x86_64
libaio-devel-0.3.109-13.el7.x86_64
libepoxy-devel-1.3.1-2.el7_5.x86_64
libfdt-devel-1.4.6-1.el7.x86_64
lzo-devel-2.06-8.el7.x86_64
make-3.82-23.el7.x86_64
mesa-libEGL-devel-17.2.3-8.20171019.el7.x86_64
mesa-libgbm-devel-17.2.3-8.20171019.el7.x86_64
nettle-devel-2.7.1-8.el7.x86_64
package g++ is not installed
package librdmacm-devel is not installed
pixman-devel-0.34.0-1.el7.x86_64
spice-glib-devel-0.34-3.el7_5.1.x86_64
spice-server-devel-0.14.0-2.el7_5.4.x86_64
tar-1.26-34.el7.x86_64
vte-devel-0.28.2-10.el7.x86_64
xen-devel-4.6.6-12.el7.x86_64
zlib-devel-1.2.7-17.el7.x86_64

Environment variables:
PACKAGES=bison bzip2 bzip2-devel ccache csnappy-devel flex  
   g++ gcc gettext git glib2-devel libaio-devel 
libepoxy-devel libfdt-devel librdmacm-devel lzo-devel make 
mesa-libEGL-devel mesa-libgbm-devel nettle-devel pixman-devel 
SDL-devel spice-glib-devel spice-server-devel tar vte-devel 
xen-devel zlib-devel
HOSTNAME=ec6a074d2e2d
MAKEFLAGS= -j8
J=8
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
TARGET_LIST=
SHLVL=1
HOME=/home/patchew
TEST_DIR=/tmp/qemu-test
FEATURES= dtc
DEBUG=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/tmp/qemu-test/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/tmp/qemu-test/install
BIOS directory/tmp/qemu-test/install/share/qemu
firmware path /tmp/qemu-test/install/share/qemu-firmware
binary directory  /tmp/qemu-test/install/bin
library directory /tmp/qemu-test/install/lib
module directory  /tmp/qemu-test/install/lib/qemu
libexec directory /tmp/qemu-test/install/libexec
include directory /tmp/qemu-test/install/include
config directory  /tmp/qemu-test/install/etc
local state directory   /tmp/qemu-test/install/var
Manual directory  /tmp/qemu-test/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
GIT binarygit
GIT submodules
C compilercc
Host C compiler   cc
C++ compiler
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2

[Qemu-devel] [Bug 1496384] Re: Error 0x5D in Qemu for Windows

2018-11-04 Thread 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/1496384

Title:
  Error 0x5D in Qemu for Windows

Status in QEMU:
  Expired

Bug description:
  The reason to use qemu for Windows is that the mouse in emulated Windows 
works well while it is unusable in  qemu at Ubuntu. 
  Alternative solution/bug is mouse usability in qemu for Linux.
  Well-known issue of error 0x5D when booting Win 7 x64 on qemu without kvm, 
marked as resolved at Linux.

  Used qemu for Windows downloaded from http://qemu.weilnetz.de/
  Tested on  qemu 2.3.94 64-bit and  qemu 2.4.0 32-bit.

  Options :
  qemu-system-x86_64.exe  -m 1536 -cpu 
qemu64,+nx,+pae,+mce,+cx8,+apic,+sep,+mtrr,+pge,+mca,+cmov,+pat,+pse36,+clflush,+acpi,+mmx,+fxsr,+sse,+sse2,+ss,+fxsr,+sse,+sse2,+ss,+de,+mtrr,+mca,+clflush
   win_7_work.qcow2

  On qemu at Ubuntu with kvm Win7 x64 works ,but mouse is unusable as
  mentioned above.

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

[Qemu-devel] [Bug 1497479] Re: memory corruption with migrate/savevm in TCG mode

2018-11-04 Thread 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/1497479

Title:
memory corruption with migrate/savevm in TCG mode

Status in QEMU:
Expired

Bug description:
[ISSUE]

QEMU releases 2.3.1 and lower are forgetting to flush TLBs before
enabling the global dirty pages log and entering the final stage of
saving the VM.

[DESCRIPTION]

The situation is the following:
1. TLB misses is the only way for page dirtying in the TCG mode.
2. If TLB is always hit by a running VM code during the execution of the
`ram_save_iterate' by migration thread then these pages are missing in the
dirty log. The TLB is always hit for instance when the VM is mostly idling and
the Kernel only handles APIC timer interrupts.
3. These pages are then missed during `ram_save_complete' stage.
4. This makes memory content in a saved VM state differ from the actual VM
memory.
5. If the affected memory pages contain some Kernel data structures these can
be corrupted by this memory inconsistency, causing Kernel to Oops after loading
the saved state.

[SOLUTION]

A proposed solution is to flush TLB when `log_global_start' is called.
Here is the patch:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1493049/+attachment/4459905/+files/tcg-commit-on-log-global-start.patch

[LINKS]

Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1493049

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

[Qemu-devel] [Bug 1496712] Re: no bootable device after qemu-img convert parallels windows 2012 r2 to raw/qcow2

2018-11-04 Thread 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/1496712

Title:
  no bootable device after qemu-img convert parallels windows 2012 r2 to
  raw/qcow2

Status in QEMU:
  Expired

Bug description:
  Hello
  We have converted a parallels windows 2012 R2 image with the command
  qemu-img convert -p -f parallels -O raw 
./TestLibvirt.pvm/TestLibvirtMig-0.hdd/TestLibvirtMig-0.hdd.0.hds 
/var/lib/libvirt/images/testlibvirtmig.raw

  Afterthat we have created a new entry with virtual machine manager and
  used this raw-hdd file as "import existing disk image"

  Then we booted this virtual server and we got the error 
  "Booting from Hard Disk"
  "no Bootable device"

  Test 1: we also tried to "overwrite" the windows server drive
  1. Create a vm with windows 2012 r2 (W2K12R2) with virtual machine manager. 
Which runs good
  2. Then we mounted in the command line the "no bootable device" server  as 
source (raw image)
  mount /ev/mapper/loop0p4 /mnt/source
  3. Then we mounted the new created (W2K12R2) as target (raw image)
  mount /ev/mapper/loop1p2 /mnt/target
  4. with the copy command we have overwritten all files on the windows drive
  rsync -av --delete /mnt/source/* /mnt/target/ 
  5. reboot the server and we have a blue screen and it tells me something 
prl_strg.sys 
   "your PC ran into a problem and needs to restart .. If you'd like to 
know more, you can search online later for this error: 
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(prl_strg.sys)

  Test 2: We also did a qemu-img convert from an ubuntu 14.04 disk and
  this works perfect.

  Thanks a lot
  Moritz

  PS: Installation of Host-Server uses: ubuntu vivid 15.04 with
  qemu-system 1:2.2+dfsg-5expubuntu9.4
  libvirt-bin 1.2.12-0ubuntu14.2
  libvirt-glib-1.0-0  0.1.9-4
  libvirt01.2.12-0ubuntu14.2
  virt-manager1:1.0.1-5ubuntu1

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

[Qemu-devel] [PATCH] blockdev: handle error on block latency histogram set error

2018-11-04 Thread zhenwei pi

Function block_latency_histogram_set may return error, but qapi ignore this.
This can be reproduced easily by qmp command:
virsh qemu-monitor-command INSTANCE '{"execute":"x-block-latency-histogram-set",
"arguments":{"device":"drive-virtio-disk1","boundaries":[10,200,40]}}'
In fact this command does not work, but we still get success result.

qmp_x_block_latency_histogram_set is a batch setting API, report error ASAP.

Signed-off-by: zhenwei pi 
---
 blockdev.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index a8755bd..03b1aa3 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -4377,6 +4377,7 @@ void qmp_x_block_latency_histogram_set(
 {
 BlockBackend *blk = blk_by_name(device);
 BlockAcctStats *stats;
+int ret;
 
 if (!blk) {
 error_setg(errp, "Device '%s' not found", device);
@@ -4392,21 +4393,33 @@ void qmp_x_block_latency_histogram_set(
 }
 
 if (has_boundaries || has_boundaries_read) {
-block_latency_histogram_set(
+ret = block_latency_histogram_set(
 stats, BLOCK_ACCT_READ,
 has_boundaries_read ? boundaries_read : boundaries);
+if (ret) {
+error_setg(errp, "Device '%s' set read boundaries fail", device);
+return;
+}
 }
 
 if (has_boundaries || has_boundaries_write) {
-block_latency_histogram_set(
+ret = block_latency_histogram_set(
 stats, BLOCK_ACCT_WRITE,
 has_boundaries_write ? boundaries_write : boundaries);
+if (ret) {
+error_setg(errp, "Device '%s' set write boundaries fail", device);
+return;
+}
 }
 
 if (has_boundaries || has_boundaries_flush) {
-block_latency_histogram_set(
+ret = block_latency_histogram_set(
 stats, BLOCK_ACCT_FLUSH,
 has_boundaries_flush ? boundaries_flush : boundaries);
+if (ret) {
+error_setg(errp, "Device '%s' set flush boundaries fail", device);
+return;
+}
 }
 }
 
-- 
2.7.4

91 matches

Mail list logo