Re: [Qemu-devel] [PATCH V2 1/3] colo-compare: introduce colo compare initlization

On 04/01/2016 01:11 PM, Jason Wang wrote: On 03/31/2016 05:24 PM, Dr. David Alan Gilbert wrote: * Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote: On 03/30/2016 05:25 PM, Dr. David Alan Gilbert wrote: * Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote: packet come from primary char

Re: [Qemu-devel] [RFC PATCH v2.1 08/12] spapr: Add CPU type specific core devices

On Thu, Mar 31, 2016 at 02:09:17PM +0530, Bharata B Rao wrote: > Introduce core devices for each CPU type supported by sPAPR. These > core devices are derived from the base spapr-cpu-core device type. > > TODO: > - Add core types for other remaining CPU types > - Handle CPU model alias correctly

Re: [Qemu-devel] [RFC PATCH v2.1 09/12] spapr: convert boot CPUs into CPU core devices

On Thu, Mar 31, 2016 at 02:09:18PM +0530, Bharata B Rao wrote: > Introduce sPAPRMachineClass.dr_cpu_enabled to indicate support for > CPU core hotplug. Initialize boot time CPUs as core deivces and prevent > topologies that result in partially filled cores. Both of these are done > only if CPU

Re: [Qemu-devel] [PATCH V2 1/3] colo-compare: introduce colo compare initlization

On 03/31/2016 05:24 PM, Dr. David Alan Gilbert wrote: > * Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote: >> >> On 03/30/2016 05:25 PM, Dr. David Alan Gilbert wrote: >>> * Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote: packet come from primary char indev will be send to outdev -

[Qemu-devel] [Bug 1563887] Re: qemu-system-ppc64 freezes on starting image on ppc64le

I'll try building the package source from kilo on the xenial host and see if that succeeds. I'm having doubts. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1563887 Title: qemu-system-ppc64

[Qemu-devel] [Bug 1563887] Re: qemu-system-ppc64 freezes on starting image on ppc64le

Hm, building 2.2.0 (close to what is in the kilo cloud archive) doesn't help. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1563887 Title: qemu-system-ppc64 freezes on starting image on ppc64le

[Qemu-devel] [Bug 1562653] Re: Ubuntu 15.10: QEMU VM hang if memory >= 1T

The issue is sloved after change cpuid[8008]; --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -2547,7 +2547,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, if (env->features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) { /* 64 bit processor */ /*

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2] spapr: compute interrupt vector address from LPCR

On Thu, Mar 31, 2016 at 03:55:42PM +1100, David Gibson wrote: > On Wed, Mar 30, 2016 at 05:38:34PM +0200, Cédric Le Goater wrote: > > This address is changed by the linux kernel using the H_SET_MODE hcall > > and needs to be restored when migrating a spapr VM running in > > TCG. This can be done

Re: [Qemu-devel] [RFC PATCH v2.1 05/12] qdev: hotplug: Introduce HotplugHandler.pre_plug() callback

On Thu, Mar 31, 2016 at 02:09:14PM +0530, Bharata B Rao wrote: > From: Igor Mammedov > > pre_plug callback is to be called before device.realize() is executed. > This would allow to check/set device's properties from HotplugHandler. > > Signed-off-by: Igor Mammedov

[Qemu-devel] [PATCH] target-ppc: Correct KVM synchronization for ppc_hash64_set_external_hpt()

ppc_hash64_set_external_hpt() was added in e5c0d3c "target-ppc: Add helpers for updating a CPU's SDR1 and external HPT". This helper contains a cpu_synchronize_state() since it may need to push state back to KVM afterwards. This turns out to break things when it is used in the reset path, which

Re: [Qemu-devel] [PATCH for-2.6] spapr_drc: enable immediate detach for unsignalled devices

Quoting David Gibson (2016-03-31 21:33:25) > On Thu, Mar 31, 2016 at 05:27:37PM -0500, Michael Roth wrote: > > Currently spapr doesn't support "aborting" hotplug of PCI > > devices by allowing device_del to immediately remove the > > device if we haven't signalled the presence of the device > > to

Re: [Qemu-devel] [PATCH] Improve documentation of FUA and FLUSH

On 03/31/2016 05:03 PM, Alex Bligh wrote: > Improve the documentation of NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA. Specifically > the latter may be set on any command, and its semantics on commands other > than NBD_CMD_WRITE need explaining. Further, explain how these relate to > reordering of commands.

[Qemu-devel] [PATCH] rtl8139: using CP_TX_OWN for ownership transferring during tx

Through CP_TX_OWN and CP_RX_OWN points to the same bit, we'd better use CP_TX_OWN for tx descriptor handling. Signed-off-by: Jason Wang --- hw/net/rtl8139.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c index

Re: [Qemu-devel] [PATCH for-2.6] spapr_drc: enable immediate detach for unsignalled devices

On Thu, Mar 31, 2016 at 05:27:37PM -0500, Michael Roth wrote: > Currently spapr doesn't support "aborting" hotplug of PCI > devices by allowing device_del to immediately remove the > device if we haven't signalled the presence of the device > to the guest. > > In the past this wasn't an issue,

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2] spapr: compute interrupt vector address from LPCR

On Thu, Mar 31, 2016 at 08:13:09AM +0100, Mark Cave-Ayland wrote: > On 31/03/16 05:55, David Gibson wrote: > > > On Wed, Mar 30, 2016 at 05:38:34PM +0200, Cédric Le Goater wrote: > >> This address is changed by the linux kernel using the H_SET_MODE hcall > >> and needs to be restored when

Re: [Qemu-devel] [PATCH for-2.7] hw/net/spapr_llan: Delay flushing of the RX queue while adding new RX buffers

On Thu, Mar 31, 2016 at 01:47:05PM +0200, Thomas Huth wrote: > Currently, the spapr-vlan device is trying to flush the RX queue > after each RX buffer that has been added by the guest via the > H_ADD_LOGICAL_LAN_BUFFER hypercall. In case the receive buffer pool > was empty before, we only pass

Re: [Qemu-devel] [PATCH] net: fix OptsVisitor memory leak

On 04/01/2016 12:22 AM, Eric Blake wrote: > On 03/31/2016 08:28 AM, Paolo Bonzini wrote: >> Signed-off-by: Paolo Bonzini > May want to add: regression introduced in commit 96a1616. > >> --- >> net/net.c | 1 + >> 1 file changed, 1 insertion(+) > Reviewed-by: Eric Blake

Re: [Qemu-devel] [patch v5 11/12] vfio: device may stuck in D3 when doing aer recovery

On 04/01/2016 09:40 AM, Chen Fan wrote: On 03/31/2016 11:44 PM, Alex Williamson wrote: On Thu, 31 Mar 2016 14:55:07 +0800 Chen Fan wrote: On 03/25/2016 10:22 AM, Alex Williamson wrote: On Fri, 25 Mar 2016 09:38:09 +0800 Chen Fan

Re: [Qemu-devel] [PATCH v5] net: Allocating Large sized arrays to heap

On 03/28/2016 08:34 PM, Pooja Dhannawat wrote: > nc_sendv_compat has a huge stack usage of 69680 bytes approx. > Moving large arrays to heap to reduce stack usage. > > Reviewed-by: Stefan Hajnoczi > Signed-off-by: Pooja Dhannawat > --- >

Re: [Qemu-devel] [PATCH v2] util: Improved qemu_hexmap() to include an ascii dump of the buffer

On 03/30/2016 03:18 PM, Thomas Huth wrote: > There's a typo in the title: qemu_hexmap should be qemu_hexdump/ instead. > > On 25.03.2016 11:42, Isaac Lozano wrote: >> qemu_hexdump() in util/hexdump.c has been changed to give also include a >> ascii dump of the buffer. Also, calls to hex_dump()

Re: [Qemu-devel] [patch v5 11/12] vfio: device may stuck in D3 when doing aer recovery

On 03/31/2016 11:44 PM, Alex Williamson wrote: On Thu, 31 Mar 2016 14:55:07 +0800 Chen Fan wrote: On 03/25/2016 10:22 AM, Alex Williamson wrote: On Fri, 25 Mar 2016 09:38:09 +0800 Chen Fan wrote: On 03/25/2016 06:54 AM, Alex

Re: [Qemu-devel] [PATCH V2 0/3] Introduce COLO-compare

On 03/31/2016 05:43 PM, Dr. David Alan Gilbert wrote: * Li Zhijian (lizhij...@cn.fujitsu.com) wrote: On 03/30/2016 08:05 PM, Dr. David Alan Gilbert wrote: * Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote: COLO-compare is a part of COLO project. It is used to compare the network package

Re: [Qemu-devel] [Bug 1563887] Re: qemu-system-ppc64 freezes on starting image on ppc64le

Thanks very much for testing. I think I have a system I can use to try and bisect tonight/tomorrow. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1563887 Title: qemu-system-ppc64 freezes on

Re: [Qemu-devel] [PATCH] xilinx_zynq: merged support for ULPI PHY and ULPI viewport from xilinx/qemu

On Wed, Mar 30, 2016 at 3:46 AM, Joscha Benz wrote: > Hi, > > On 29.03.2016 22:23, Alistair Francis wrote: >> On Tue, Mar 29, 2016 at 12:51 PM, wrote: >>> Signed-off-by: Joscha Benz >> >> Hello Joscha , >> >> Thanks for the patch. In

Re: [Qemu-devel] [PATCH v2 1/1] NBD proto: add WRITE_ZEROES extension

On 03/31/2016 07:02 AM, Denis V. Lunev wrote: > From: Pavel Borzenkov > > There exist some cases when a client knows that the data it is going to > write is all zeroes. Such cases include mirroring or backing up a device > implemented by a sparse file. > > With current

[Qemu-devel] [PATCH] Docs: proto.md: Clarify NUL in export name

Clarify that * The name is not NUL terminated (not just that the length 'does not include NUL termination' which might be taken to mean there is NUL termination but the length doesn't include it. * The name cannot itself include embedded NUL characters (despite it not being NUL

[Qemu-devel] [PATCH] Improve documentation of FUA and FLUSH

Improve the documentation of NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA. Specifically the latter may be set on any command, and its semantics on commands other than NBD_CMD_WRITE need explaining. Further, explain how these relate to reordering of commands. Signed-off-by: Alex Bligh ---

Re: [Qemu-devel] Why is SeaBIOS used with -kernel?

On Thu, Mar 31, 2016 at 11:17:30PM +0100, Richard W.M. Jones wrote: > On Thu, Mar 31, 2016 at 12:22:23PM -0400, Kevin O'Connor wrote: > > On Thu, Mar 31, 2016 at 10:21:25AM +0100, Stefan Hajnoczi wrote: > > > On Sat, Mar 19, 2016 at 08:31:24PM +, Richard W.M. Jones wrote: > > > > Is there

[Qemu-devel] [PATCH for-2.6] spapr_drc: enable immediate detach for unsignalled devices

Currently spapr doesn't support "aborting" hotplug of PCI devices by allowing device_del to immediately remove the device if we haven't signalled the presence of the device to the guest. In the past this wasn't an issue, since we always immediately signalled device attach and simply relied on

Re: [Qemu-devel] [PATCH] slirp: Fix migration from older versions of QEMU to the current one

Samuel Thibault, on Fri 01 Apr 2016 00:00:43 +0200, wrote: > Just realizing... We'd need to add AF_INET6 cases here too, to be able > to save/restore a VM using ipv6 connections. That seems quite involved however, maybe we should postpone that to later? Samuel

[Qemu-devel] [PULL] slirp: Fix migration from older versions of QEMU to the current one

From: Thomas Huth While adding the IPv6 support, the commit eae303ff23f51259eddc8856c71453d8 ("slirp: Make Socket structure IPv6 compatible") changed the format of the migration stream, without taking into account that we might still receive an old migration stream layout when

[Qemu-devel] [PULL] slirp updates

MAINTAINERS: Delete invalid maintainer entries of the Exynos section (2016-03-31 18:21:01 +0100) are available in the git repository at: http://people.debian.org/~sthibault/qemu.git tags/samuel-thibault-2 for you to fetch changes up to eaf136f9a21e02a2f55346e44d2d88df37b2cde3: slirp:

Re: [Qemu-devel] Why is SeaBIOS used with -kernel?

[This time without the massive attachment] On Thu, Mar 31, 2016 at 12:22:23PM -0400, Kevin O'Connor wrote: > On Thu, Mar 31, 2016 at 10:21:25AM +0100, Stefan Hajnoczi wrote: > > On Sat, Mar 19, 2016 at 08:31:24PM +, Richard W.M. Jones wrote: > > > Is there something I'm missing, or for Linux

Re: [Qemu-devel] [PATCH] slirp: Fix migration from older versions of QEMU to the current one

Thomas Huth, on Thu 31 Mar 2016 16:48:41 +0200, wrote: > While adding the IPv6 support, the commit eae303ff23f51259eddc8856c71453d8 > ("slirp: Make Socket structure IPv6 compatible") changed the format of > the migration stream, without taking into account that we might still > receive an old

[Qemu-devel] [PATCH 1/3] nbd: Treat flags vs. command type as separate fields

Current upstream NBD documents that requests have a 16-bit flags, followed by a 16-bit type integer; although older versions mentioned only a 32-bit field with masking to find flags. Since the protocol is in network order (big-endian over the wire), the ABI is unchanged; but dealing with the

[Qemu-devel] [PATCH 3/3] nbd: Reject unknown request flags

The NBD protocol says that clients should not send a command flag that has not been negotiated (whether by the client requesting an option during a handshake, or because we advertise support for the flag in response to NBD_OPT_EXPORT_NAME), and that servers should reject invalid flags with EINVAL.

[Qemu-devel] [PATCH 2/3] nbd: Fix poor debug message

The client sends messages to the server, not itself. Signed-off-by: Eric Blake --- nbd/client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nbd/client.c b/nbd/client.c index 5af9f26..d95ad7a 100644 --- a/nbd/client.c +++ b/nbd/client.c @@ -635,7 +635,7

[Qemu-devel] [PATCH 0/3] NBD: flag handling cleanup

I'm currently helping with work on adding extensions to the upstream NBD protocol to allow more efficient handling of sparse files, and wanted to get my feet wet in the qemu NBD code (both client and server), to actually implement those proposals to see how well they work. In the process, I found

Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?

On 03/31/2016 02:17 PM, Alex Bligh wrote: > OK so I actually went and researched what my answer was last time I > was asked ( :-) ): > > Here was my conclusion last time after trawling through lkml > on the subject: > > From https://sourceforge.net/p/nbd/mailman/message/27569820/ > >> You may

[Qemu-devel] [Bug 1563887] Re: qemu-system-ppc64 freezes on starting image on ppc64le

I have installed qemu-slof from trusty and ran again: qemu-slof: Installed: 20151103+dfsg-1ubuntu1 Candidate: 20151103+dfsg-1ubuntu1 Version table: *** 20151103+dfsg-1ubuntu1 500 500 http://ports.ubuntu.com/ubuntu-ports xenial/main ppc64el Packages 100 /var/lib/dpkg/status

Re: [Qemu-devel] [PATCH 2/2] Correct definition of NBD_CMD_FLAG_FUA

On 31 Mar 2016, at 21:07, Eric Blake wrote: >> >> or include/uapi/linux/nbd.h ; these have no reference to FUA at all, > > I'm not finding that file on my system; not sure what it contains, or > where it is maintained. files have moved around in the kernel, and the

Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?

On 31 Mar 2016, at 20:54, Eric Blake wrote: > > Oh, and I also just found that qemu's nbd-server tries to honor FUA on > read, even though the protocol doesn't document that as valid either. Potentially useful, but I believe not required (I don't believe the kernel does

Re: [Qemu-devel] [PATCH 2/2] Correct definition of NBD_CMD_FLAG_FUA

On 03/31/2016 01:25 PM, Alex Bligh wrote: > > On 31 Mar 2016, at 20:14, Eric Blake wrote: > >>> >>> >>> Should we produce a new name for it (and future command flags) >>> that aren't shifted left 16 places, and just maintain the >>> current value for compatibility? >> >> I

Re: [Qemu-devel] tcg: reworking tb_invalidated_flag

On 31/03/2016 21:03, Sergey Fedorov wrote: > Looks like we have to ensure all vCPUs are out of translated code when > doing TB patching either doing tb_add_jump() or tb_phys_invalidate(). > Did I missed something? Almost all TCG targets have naturally aligned instructions, so that's not a

Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?

On 03/31/2016 01:41 PM, Alex Bligh wrote: > > On 31 Mar 2016, at 20:33, Eric Blake wrote: > >> Qemu's nbd-client is setting NBD_CMD_FLAG_FUA during a flush command, >> but the official NBD protocol documentation doesn't describe this as >> valid (it merely states that flush

Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?

On 31 Mar 2016, at 20:33, Eric Blake wrote: > Qemu's nbd-client is setting NBD_CMD_FLAG_FUA during a flush command, > but the official NBD protocol documentation doesn't describe this as > valid (it merely states that flush must not have a reply until all > acknowledged

[Qemu-devel] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?

Qemu's nbd-client is setting NBD_CMD_FLAG_FUA during a flush command, but the official NBD protocol documentation doesn't describe this as valid (it merely states that flush must not have a reply until all acknowledged writes have hit permanent storage). Does this flag make sense (what semantics

Re: [Qemu-devel] [PATCH 2/2] Correct definition of NBD_CMD_FLAG_FUA

On 31 Mar 2016, at 20:14, Eric Blake wrote: >> >> >> Should we produce a new name for it (and future command flags) >> that aren't shifted left 16 places, and just maintain the >> current value for compatibility? > > I don't see the point. Your fix looks correct. OK. And

Re: [Qemu-devel] [Qemu-stable] [PATCH] target-i386: do not read/write MSR_TSC_AUX from KVM if CPUID bit is not set

Am 31.03.2016 um 18:52 schrieb Paolo Bonzini: > > On 31/03/2016 17:38, Peter Lieven wrote: >> >>> Am 31.03.2016 um 15:23 schrieb Paolo Bonzini : >>> >>> >>> On 31/03/2016 15:12, Peter Lieven wrote: >> KVM does not let you read or write this MSR if the corresponding

Re: [Qemu-devel] [PATCH 2/2] Correct definition of NBD_CMD_FLAG_FUA

On 03/31/2016 12:21 PM, Alex Bligh wrote: > > On 31 Mar 2016, at 19:15, Alex Bligh wrote: > >> It is doubtful whether anyone is using NBD_CMD_FLAG_FUA >> at the moment in any case. > > Drat. I spoke too soon. Qemu uses it, but presumably from its > own .h file. Yes, qemu has

Re: [Qemu-devel] [PATCH 1/2] proto.md: Clearly set out NBDMAGIC is the actual value

On 03/31/2016 12:15 PM, Alex Bligh wrote: > Clearly set out NBDMAGIC, not the name of a constant equal to > some value. Set out the value in hex as well. > > Signed-off-by: Alex Bligh > --- > doc/proto.md | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff

Re: [Qemu-devel] tcg: reworking tb_invalidated_flag

On 31/03/16 17:06, Sergey Fedorov wrote: > It should be safe to invalidate a TB while some other CPU is executing > its translated code. Probably it's not safe to invalidate a TB while some other thread is executing the translated code. Direct jumps to the TB being invalidated should be reset. In

[Qemu-devel] q35 migration broken

Hi, I'm seeing a breakage on q35 migration on head (and possibly older but certainly head; it's also on a 2.5.0 world I've got with a bunch of patches but I've not tried a clean 2.5.0 yet). It looks like some type of interrupt screwup; with a virtio-net device I get a: BUG: soft lockup -

Re: [Qemu-devel] [PATCH 2/2] Correct definition of NBD_CMD_FLAG_FUA

On 31 Mar 2016, at 19:15, Alex Bligh wrote: > It is doubtful whether anyone is using NBD_CMD_FLAG_FUA > at the moment in any case. Drat. I spoke too soon. Qemu uses it, but presumably from its own .h file. However, it's now nonsensical having it defined as 1<<16 in a 16 bit

[Qemu-devel] [Bug 1563887] Re: qemu-system-ppc64 freezes on starting image on ppc64le

Failing any brighter ideas, this should be pretty bisectable to figure out what happened. Hardware availability is the main problem. Would you be able to use your system to bisect to the commit introducing the bug? Actually before we get to that, could you try installing the 14.04 slof package

[Qemu-devel] [PATCH 2/2] Correct definition of NBD_CMD_FLAG_FUA

NBD_CMD_FLAG_FUA is defined as 1<<0 in the documentation, but 1<<16 in nbd.h. It is not used anywhere within the code. 1<<16 cannot work as the flags word is only 16 bits long. It is doubtful whether anyone is using NBD_CMD_FLAG_FUA at the moment in any case. Signed-off-by: Alex Bligh

[Qemu-devel] [PATCH 1/2] proto.md: Clearly set out NBDMAGIC is the actual value

Clearly set out NBDMAGIC, not the name of a constant equal to some value. Set out the value in hex as well. Signed-off-by: Alex Bligh --- doc/proto.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/proto.md b/doc/proto.md index c1e05c5..7994076

[Qemu-devel] Ballooning on TPS!=HPS hosts

Hi, I was reading the balloon code and am confused as to how/if ballooning works on hosts where the host page size is larger than the target page size. static void balloon_page(void *addr, int deflate) { #if defined(__linux__) if (!qemu_balloon_is_inhibited() && (!kvm_enabled() ||

Re: [Qemu-devel] tcg/ppc: maintainer's mail delivery failure

On 03/31/2016 10:30 AM, Peter Maydell wrote: > On 24 March 2016 at 11:09, Peter Maydell wrote: >> On 24 March 2016 at 10:55, Sergey Fedorov wrote: >>> Probably we don't have a maintainer for PPC TCG backend. >>> >>> PPC >>> M: Vassili

Re: [Qemu-devel] tcg/ppc: maintainer's mail delivery failure

On 24 March 2016 at 11:09, Peter Maydell wrote: > On 24 March 2016 at 10:55, Sergey Fedorov wrote: >> Probably we don't have a maintainer for PPC TCG backend. >> >> PPC >> M: Vassili Karpov (malc) >> S: Maintained

Re: [Qemu-devel] [PATCH] Xen: update MAINTAINERS info

On 29 March 2016 at 11:02, Stefano Stabellini wrote: > Add Anthony Perard as Xen co-maintainer. > Update my email address. > > Signed-off-by: Stefano Stabellini > Acked-by: Anthony Perard > > diff

Re: [Qemu-devel] [PATCH] MAINTAINERS: Delete invalid maintainer entries of the Exynos section

On 30 March 2016 at 13:32, Thomas Huth wrote: > Mails to these e-mail addresses are rejected by the mail server > of Samsung with "User unknown" messages, so it seems like these > Exynos maintainers are no longer available. > > Signed-off-by: Thomas Huth > ---

Re: [Qemu-devel] [FreeBSD] Host build i386 failing to build aarch64 targets

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This seems to at least allow things to compile, qemu-system seems to be able to boot images on i386, but I may have missed something: diff --git a/cpus.c b/cpus.c index 23cf7aa..11f8bab 100644 - --- a/cpus.c +++ b/cpus.c @@ -338,15 +338,8 @@ static

Re: [Qemu-devel] [Qemu-stable] [PATCH] target-i386: do not read/write MSR_TSC_AUX from KVM if CPUID bit is not set

On 31/03/2016 17:38, Peter Lieven wrote: > > >> Am 31.03.2016 um 15:23 schrieb Paolo Bonzini : >> >> >> >>> On 31/03/2016 15:12, Peter Lieven wrote: > > KVM does not let you read or write this MSR if the corresponding CPUID > bit is not set. This in turn

Re: [Qemu-devel] [PATCH] target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs

On Thu, Mar 31, 2016 at 03:01:29PM +0200, Laszlo Ersek wrote: > On 03/30/16 22:59, Paolo Bonzini wrote: > > This would have caught the bug in the previous patch. > > Should this patch share a series with > ? Otherwise > they could be

Re: [Qemu-devel] [PATCH v2] migration: skip sending ram pages released by virtio-balloon driver.

* Jitendra Kolhe (jitendra.ko...@hpe.com) wrote: > While measuring live migration performance for qemu/kvm guest, it > was observed that the qemu doesn’t maintain any intelligence for the > guest ram pages which are released by the guest balloon driver and > treat such pages as any other normal

Re: [Qemu-devel] [PATCH 2/2] target-mips: Implement IEEE 754-2008 functionality for R6 and MSA instructions

On 03/31/2016 04:55 AM, Aleksandar Markovic wrote: > Hi, Richard, what would you think about this approach: > > Functionality of . and .. > instructions is dependent on flags ABS2008 and NAN2008 in FCR31. There are > MIPS architectures (for

Re: [Qemu-devel] [PATCH] target-i386: do not read/write MSR_TSC_AUX from KVM if CPUID bit is not set

On Wed, Mar 30, 2016 at 10:59:42PM +0200, Paolo Bonzini wrote: > KVM does not let you read or write this MSR if the corresponding CPUID > bit is not set. This in turn causes MSRs that come after MSR_TSC_AUX > to be ignored by KVM_SET_MRSS. > > One visible symptom is that s3.flat from

Re: [Qemu-devel] tcg: reworking tb_invalidated_flag

On 03/31/2016 05:42 AM, Sergey Fedorov wrote: > On 31/03/16 13:48, Alex Bennée wrote: >> I know we are system focused at the moment but does linux-user ever >> flush groups of TBs, say when mappings change? Or does this trigger a >> whole tb_flush? > > Yes, e.g. target_mmap() calls

Re: [Qemu-devel] Virtio-9p

On Wed, 30 Mar 2016 16:27:48 +0200 Pradeep Kiruvale wrote: > Hi Greg, > Hi Pradeep, > Thanks for the reply. > > Let me put it this way, virtio-blk-pci is used for block IO on the devices > shared between the guest and the host. I don't really understand the

Re: [Qemu-devel] Why is SeaBIOS used with -kernel?

On Thu, Mar 31, 2016 at 10:21:25AM +0100, Stefan Hajnoczi wrote: > On Sat, Mar 19, 2016 at 08:31:24PM +, Richard W.M. Jones wrote: > > Is there something I'm missing, or for Linux + -kernel could we use a > > much simpler BIOS? > > The data that Marc Mari collected when comparing qboot with

Re: [Qemu-devel] [PATCH] net: fix OptsVisitor memory leak

On 03/31/2016 08:28 AM, Paolo Bonzini wrote: > Signed-off-by: Paolo Bonzini May want to add: regression introduced in commit 96a1616. > --- > net/net.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Eric Blake > > diff --git a/net/net.c

Re: [Qemu-devel] [PATCH v1] net: fix missing include of qapi/error.h in netmap.c

On 03/31/2016 07:08 AM, Daniel P. Berrange wrote: > The netmap.c file fails to build on FreeBSD with > > net/netmap.c:95:9: warning: implicit declaration of function > 'error_setg_errno' is invalid in C99 [-Wimplicit-function-declaration] > error_setg_errno(errp, errno, "Failed to nm_open()

Re: [Qemu-devel] [patch v5 11/12] vfio: device may stuck in D3 when doing aer recovery

On Thu, 31 Mar 2016 14:55:07 +0800 Chen Fan wrote: > On 03/25/2016 10:22 AM, Alex Williamson wrote: > > On Fri, 25 Mar 2016 09:38:09 +0800 > > Chen Fan wrote: > > > >> On 03/25/2016 06:54 AM, Alex Williamson wrote: > >>> On Wed, 23

Re: [Qemu-devel] [Qemu-stable] [PATCH] target-i386: do not read/write MSR_TSC_AUX from KVM if CPUID bit is not set

> Am 31.03.2016 um 15:23 schrieb Paolo Bonzini : > > > >> On 31/03/2016 15:12, Peter Lieven wrote: KVM does not let you read or write this MSR if the corresponding CPUID bit is not set. This in turn causes MSRs that come after MSR_TSC_AUX to be

[Qemu-devel] [PATCH v2 0/2] Fixing non-blocking operation of chardevs

This fixes socket chardevs to always be in non-blocking mode, as they were before the QIOChannel conversion. The second patch was already posted before, but dropped when Peter discovered a problem on OS-X causing ahci-test to hang:

[Qemu-devel] [PATCH v2 1/2] char: fix broken EAGAIN retry on OS-X due to errno clobbering

Some of the chardev I/O paths really want to write the complete data buffer even though the channel is in non-blocking mode. To achieve this they look for EAGAIN and g_usleep() for 100ms. Unfortunately the code is set to check errno == EAGAIN a second time, after the g_usleep() call has completed.

[Qemu-devel] [PATCH v2 2/2] char: ensure all clients are in non-blocking mode

Only some callers of tcp_chr_new_client are putting the socket client into non-blocking mode. Move the call to qio_channel_set_blocking() into the tcp_chr_new_client method to guarantee that all code paths set non-blocking mode Reported-by: Andrew Baumann

[Qemu-devel] [PATCH 2/4] target-arm: Remove incorrect ALIAS tags from ESR_EL2 and ESR_EL3

The regdefs for the ESR_EL2 and ESR_EL3 system registers should not be marked as ARM_CP_ALIAS, because these are the master copies; the DFSR regdef in vmsa_pmsa_cp_reginfo[] is marked as an alias. Remove the ALIAS tags so that these registers are correctly migrated. Signed-off-by: Peter Maydell

Re: [Qemu-devel] [PATCH 1/4] target-arm: Correctly reset SCTLR_EL3 for 64-bit CPUs

On Thu, Mar 31, 2016 at 4:49 PM, Peter Maydell wrote: > The regdef for SCTRL_EL3 was incorrectly marked as being an > ARM_CP_ALIAS, with the remark that this was because the 32-bit > definition would take care of reset and migration. However the > intention for banked

[Qemu-devel] [PATCH for-2.6 0/4] various regdef fixes for EL2/EL3 regs

This patchset fixes a number of minor bugs in regdefs for some EL2 and EL3 registers. The most interesting one here is the first -- we weren't resetting SCTLR_EL3 correctly for 64-bit CPUs. The rest are things I discovered by code inspection looking at other registers: * we weren't migrating

[Qemu-devel] [PATCH 1/4] target-arm: Correctly reset SCTLR_EL3 for 64-bit CPUs

The regdef for SCTRL_EL3 was incorrectly marked as being an ARM_CP_ALIAS, with the remark that this was because the 32-bit definition would take care of reset and migration. However the intention for banked registers as documented in the comment in add_cpreg_to_hashtable() is: * 2) If ARMv8 is

[Qemu-devel] [PATCH 3/4] target-arm: Make the 64-bit version of VTCR do the migration

Move the ALIAS tag from VTCR_EL2 to VTCR so that we migrate the 64-bit version, as is usual. (This has no particular effect now unless the guest wrote to the high RES0 bits of VTCR_EL2.) Add a comment about why it's OK that we don't have the various accessor functions that the EL1 TCR regdefs do.

Re: [Qemu-devel] [PULL 0/5] ipv4-only and ipv6-only support

Peter Maydell, on Thu 31 Mar 2016 15:44:13 +0100, wrote: > if (get_dns6_addr(>sin6_addr, > >sin6_scope_id) < 0) { > ^ > In file included from > /home/petmay01/linaro/qemu-for-merges/slirp/slirp.h:99:0, > from

[Qemu-devel] [PATCH 4/4] target-arm: Avoid unnecessary TLB flush on TCR_EL2 writes

The TCR_EL2 regdef was incorrectly using the vmsa_tcr_el1_write function for writes. Since TCR_EL2 doesn't have the A1 bit that TCR_EL1 does, we don't need to do a tlb_flush() when it is written. Remove the unnecessary .writefn and also the harmless but unneeded .raw_writefn and .resetfn

[Qemu-devel] [PATCH] slirp: Fix migration from older versions of QEMU to the current one

While adding the IPv6 support, the commit eae303ff23f51259eddc8856c71453d8 ("slirp: Make Socket structure IPv6 compatible") changed the format of the migration stream, without taking into account that we might still receive an old migration stream layout when upgrading from QEMU version 2.5 (or

Re: [Qemu-devel] [PATCH 1/2] char: fix broken EAGAIN retry on OS-X due to errno clobbering

On Thu, Mar 31, 2016 at 03:35:44PM +0100, Peter Maydell wrote: > On 31 March 2016 at 15:29, Daniel P. Berrange wrote: > > Some of the chardev I/O paths really want to write the > > complete data buffer even though the channel is in > > non-blocking mode. To achieve this they

Re: [Qemu-devel] tcg: reworking tb_invalidated_flag

On 31/03/2016 16:35, Sergey Fedorov wrote: >> > My plan was to use some kind of double buffering, where only half of >> > code_gen_buffer is in use. At the end of tb_flush you call cpu_exit() >> > on all CPUs, so that CPUs stop executing chained TBs from the old half >> > before they can see

Re: [Qemu-devel] [PULL 0/5] ipv4-only and ipv6-only support

On 31 March 2016 at 15:19, Samuel Thibault wrote: > Peter Maydell, on Thu 31 Mar 2016 15:11:27 +0100, wrote: >> On 31 March 2016 at 13:51, Samuel Thibault wrote: >> > Peter Maydell, on Thu 31 Mar 2016 13:47:28 +0100, wrote: >> >> On 31 March 2016

Re: [Qemu-devel] tcg: reworking tb_invalidated_flag

On 31/03/16 16:40, Paolo Bonzini wrote: > > On 31/03/2016 15:14, Sergey Fedorov wrote: >> On 30/03/16 21:13, Paolo Bonzini wrote: >>> On 30/03/2016 19:08, Sergey Fedorov wrote: The second approach is to make 'tb_invalidated_flag' per-CPU. This would be conceptually similar to what we

Re: [Qemu-devel] [PATCH v2 1/1] NBD proto: add WRITE_ZEROES extension

On 31/03/2016 16:27, Alex Bligh wrote: > > > IE why not always permit trimming PROVIDED the data always reads back > > > as zero? This would be far simpler. > > > > Because trimming can make future operations more expensive and cause > > fragmentation (which may not be as bad as it used to be

Re: [Qemu-devel] [PATCH v2 1/1] NBD proto: add WRITE_ZEROES extension

On 31 Mar 2016, at 14:55, Paolo Bonzini wrote: > On 31/03/2016 15:53, Alex Bligh wrote: +If the flag `NBD_CMD_FLAG_MAY_TRIM` was set by the client in the command +flags field, the server MAY use trimming to zero out the area, but it +MUST

Re: [Qemu-devel] [PATCH 1/2] char: fix broken EAGAIN retry on OS-X due to errno clobbering

On 31 March 2016 at 15:29, Daniel P. Berrange wrote: > Some of the chardev I/O paths really want to write the > complete data buffer even though the channel is in > non-blocking mode. To achieve this they look for EAGAIN > and g_usleep() for 100ms. Unfortunately the code is

[Qemu-devel] [PATCH 1/2] char: fix broken EAGAIN retry on OS-X due to errno clobbering

Some of the chardev I/O paths really want to write the complete data buffer even though the channel is in non-blocking mode. To achieve this they look for EAGAIN and g_usleep() for 100ms. Unfortunately the code is set to check errno == EAGAIN a second time, after the g_usleep() call has completed.

[Qemu-devel] [PATCH 2/2] char: ensure all clients are in non-blocking mode

Only some callers of tcp_chr_new_client are putting the socket client into non-blocking mode. Move the call to qio_channel_set_blocking() into the tcp_chr_new_client method to guarantee that all code paths set non-blocking mode Reported-by: Andrew Baumann

[Qemu-devel] [PATCH 0/2] Fixing non-blocking operation of chardevs

This fixes socket chardevs to always be in non-blocking mode, as they were before the QIOChannel conversion. The second patch was already posted before, but dropped when Peter discovered a problem on OS-X causing ahci-test to hang:

[Qemu-devel] [PATCH] net: fix OptsVisitor memory leak

Signed-off-by: Paolo Bonzini --- net/net.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/net.c b/net/net.c index 594c3b8..3847a13 100644 --- a/net/net.c +++ b/net/net.c @@ -1100,6 +1100,7 @@ int net_client_init(QemuOpts *opts, int is_netdev, Error **errp) }

Re: [Qemu-devel] [PULL 0/5] ipv4-only and ipv6-only support

Peter Maydell, on Thu 31 Mar 2016 15:11:27 +0100, wrote: > On 31 March 2016 at 13:51, Samuel Thibault wrote: > > Peter Maydell, on Thu 31 Mar 2016 13:47:28 +0100, wrote: > >> On 31 March 2016 at 10:20, Samuel Thibault > >> wrote: > >> >

Re: [Qemu-devel] [PULL 0/5] ipv4-only and ipv6-only support

On 31 March 2016 at 13:51, Samuel Thibault wrote: > Peter Maydell, on Thu 31 Mar 2016 13:47:28 +0100, wrote: >> On 31 March 2016 at 10:20, Samuel Thibault >> wrote: >> > Update version for v2.6.0-rc0 release (2016-03-30 19:25:40 +0100) >>

Re: [Qemu-devel] [PATCH v2 1/1] NBD proto: add WRITE_ZEROES extension

On 03/31/2016 07:53 AM, Alex Bligh wrote: > > On 31 Mar 2016, at 14:02, Denis V. Lunev wrote: > >> From: Pavel Borzenkov >> >> There exist some cases when a client knows that the data it is going to >> write is all zeroes. Such cases include mirroring

  1   2   3   >