On 26.01.2017 16:38, Stefan Hajnoczi wrote:
> This hunk should not have been merged but I forgot to remove it. Let's
> remove it before it slips into a QEMU release.
Too late - looks like this patch has never been committed :-(
>
> Signed-off-by: Stefan Hajnoczi
> ---
> aio-posix.c | 7 --
Public bug reported:
My host environment: Xen + QEMU
git clones today's xen git and qemut git (2017-10-31)
xen -- git://xenbits.xen.org/xen.git
commit 24fb44e971a62b345c7b6ca3c03b454a1e150abe
qemu -- https://github.com/qemu/qemu
commit 47ba789c97c8d201d01058b00a14d8a9a85fcfe9
QEMU wa
> unknown keycodes `(unnamed)', please report to qemu-devel@nongnu.org
This message appears when I type the first character of my password
after booting a virtual machine that is running ubuntu 17.10 (command line
below). The host and guest are both running ubuntu 17.10.
I did not see the messag
Hi Markus,
On 10/09/2017 04:24 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> Imported from Markus Armbruster commit b45c03f
>>
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> Signed-off-by: Markus Armbruster ?
>>
>> scripts/coccinelle/g_new.cocci | 101
>> +
Hi Markus,
On 10/09/2017 03:46 AM, Markus Armbruster wrote:
> Please cc me on changes to stuff I maintain, as scripts/get_maintainer
> tells you :)
Oops I might have been a copy/paste error.
> Philippe Mathieu-Daudé writes:
>
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> scripts/coverit
Hi all,
I'm debugging a mis-unmap bug in ovs-dpdk, process is this:
1. start ovs-dpdk with 10G socket memory, then use `top`, ovs-vswitchd take
10G memory. command is bellow.
2. start qemu vm1 with vhost device as server to connect port on ovs-dpdk,
command is bellow. qemu share 40G memory with o
On 11/01/2017 11:10 PM, Pavel Pisa wrote:
>>> Some page about the project
>>>
>>> https://gitlab.fel.cvut.cz/canbus/qemu-canbus/wikis/home
>>>
>>> FEE CTU GitLab repository with can-pci branch for 2.3, 2.4, 2.7, 2.8 and
>>> 2.10 version if QEMU is available there
>>>
>>> https://gitlab.fel.cvut
On 11/01/2017 10:00 PM, p...@cmp.felk.cvut.cz wrote:
> From: Pavel Pisa
>
> Signed-off-by: Pavel Pisa
> ---
> default-configs/pci.mak | 1 +
> hw/can/Makefile.objs| 1 +
> hw/can/can_kvaser_pci.c | 376
>
> 3 files changed, 378 insertion
Hi Pavel,
On 11/01/2017 10:00 PM, p...@cmp.felk.cvut.cz wrote:
> From: Pavel Pisa
>
> The core SJA1000 support is independent of following
> patches which map SJA1000 chip to PCI boards.
>
> The work is based on Jin Yang GSoC 2013 work funded
> by Google and mentored in frame of RTEMS project G
Hello Philippe,
On Thursday 02 of November 2017 02:27:18 Philippe Mathieu-Daudé wrote:
> On 11/01/2017 10:00 PM, p...@cmp.felk.cvut.cz wrote:
> > Some page about the project
> >
> > https://gitlab.fel.cvut.cz/canbus/qemu-canbus/wikis/home
> >
> > FEE CTU GitLab repository with can-pci branch for
more comments after reading your next patch.
On 11/01/2017 10:00 PM, p...@cmp.felk.cvut.cz wrote:
[...]
> diff --git a/include/can/can_emu.h b/include/can/can_emu.h
> new file mode 100644
> index 00..86b35aef32
> --- /dev/null
> +++ b/include/can/can_emu.h
> @@ -0,0 +1,133 @@
> +/*
> + * C
Hi Pavel,
On 11/01/2017 10:00 PM, p...@cmp.felk.cvut.cz wrote:
> From: Pavel Pisa
>
> The CanBusState state structure is created for each
> emulated CAN channel. Individual clients/emulated
> CAN interfaces or host interface connection registers
> to the bus by CanBusClientState structure.
>
>
Hi Pavel,
On 11/01/2017 10:00 PM, p...@cmp.felk.cvut.cz wrote:
> Some page about the project
>
> https://gitlab.fel.cvut.cz/canbus/qemu-canbus/wikis/home
>
> FEE CTU GitLab repository with can-pci branch for 2.3, 2.4, 2.7, 2.8 and 2.10
> version if QEMU is available there
>
> https://gitlab
>>> I think that currently we try to make "--help" work
>>> even if you don't have a working C compiler. Does this
>>> break that?
>>
>> Just checked, configure --help isn't broken with this change:
>
> Did you test with gcc uninstalled again? It's hard to see
> how it could work -- if the compile
On 28/10/17 19:25, Paolo Bonzini wrote:
> On 28/10/2017 08:57, Alexey Kardashevskiy wrote:
>> On 27/10/17 18:12, Jeff Cody wrote:
>>> VHDX does not support migration (VMDK fails the same way).
>>
>> Probably a very ignorant question but how can an image format not support
>> migration at all? Is n
On 31/10/17 00:10, Jeff Cody wrote:
> Changes from v1->v2:
>
> * Drop previous parallels patches, just check BDRV_O_INACTIVE now
> (Kevin)
>
> git-backport-diff -r qemu/master.. -u github/master
> Key:
> [] : patches are identical
> [] : number of functional differences between upstream
From: Deniz Eren
Signed-off-by: Pavel Pisa
---
hw/can/Makefile.objs | 1 +
hw/can/can_mioe3680_pci.c | 335 ++
2 files changed, 336 insertions(+)
create mode 100644 hw/can/can_mioe3680_pci.c
diff --git a/hw/can/Makefile.objs b/hw/can/Makefile
From: Pavel Pisa
The core SJA1000 support is independent of following
patches which map SJA1000 chip to PCI boards.
The work is based on Jin Yang GSoC 2013 work funded
by Google and mentored in frame of RTEMS project GSoC
slot donated to QEMU.
Rewritten for QEMU-2.0+ versions and architecture c
From: Deniz Eren
Signed-off-by: Pavel Pisa
---
hw/can/Makefile.objs | 1 +
hw/can/can_pcm3680_pci.c | 335 +++
2 files changed, 336 insertions(+)
create mode 100644 hw/can/can_pcm3680_pci.c
diff --git a/hw/can/Makefile.objs b/hw/can/Makefile.o
From: Pavel Pisa
Signed-off-by: Pavel Pisa
---
default-configs/pci.mak | 1 +
hw/can/Makefile.objs| 1 +
hw/can/can_kvaser_pci.c | 376
3 files changed, 378 insertions(+)
create mode 100644 hw/can/can_kvaser_pci.c
diff --git a/default-c
From: Pavel Pisa
The CanBusState state structure is created for each
emulated CAN channel. Individual clients/emulated
CAN interfaces or host interface connection registers
to the bus by CanBusClientState structure.
Connection to the real host CAN bus network through
SocketCAN network interface
From: Pavel Pisa
Basic emulation of CAN bus controller and interconnection for QEMU.
Patches version 2:
The bus emulation and the SJA1000 chip emulation introduced
by individual patches as suggested by Frederic Konrad.
Simple example board to test SJA1000 as single memory-mapped BAR
has been omi
On 1 November 2017 at 19:46, Daniel Henrique Barboza
wrote:
> On 11/01/2017 05:41 PM, Peter Maydell wrote:
>> I think that currently we try to make "--help" work
>> even if you don't have a working C compiler. Does this
>> break that?
>
> Just checked, configure --help isn't broken with this chang
On 10/24/2017 11:56 AM, Philippe Mathieu-Daudé wrote:
> Hi Alistair,
>
> On 10/19/2017 01:16 PM, Alistair Francis wrote:
>> Replace a large number of the fprintf(stderr, "*\n" calls with
>> error_report(). The functions were renamed with these commands and then
>> compiler issues where manually
Hi,
This series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.
Subject: [Qemu-devel] [PATCH v2] configure: adding ppc64le to supported host
CPUs
Type: series
Message-id: 20171101191030.161
On 1 November 2017 at 20:20, mar.krzeminski
wrote:
> Hi Francisco,
>
> W dniu 01.11.2017 o 08:16, Francisco Iglesias pisze:
>
> Add support for continuous read out of the RDSR and READ_FSR status
>> registers until the chip select is deasserted. This feature is supported
>> by amongst others 1 or
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [RFCPATCH10/20] icount: fixed saving/restoring of icount
warp timers
Type: series
Message-id: 20171031104835.3079.2722.stgit@pasha-VirtualBox
=== TEST SCRIPT BEGIN ===
#!/bin/b
On Wed, Nov 01, 2017 at 18:34:23 +0100, Thomas Huth wrote:
> Seems like something in this patch series broke a couple of ARM boards
> (smdkc210, nuri, raspi2, xlnx-ep108 and xlnx-zcu102). With current
> master branch, I just get this error:
>
> $ aarch64-softmmu/qemu-system-aarch64 -machine raspi
On 11/01/2017 05:41 PM, Peter Maydell wrote:
On 1 November 2017 at 19:31, Daniel Henrique Barboza
wrote:
When executing 'configure' in a fresh QEMU clone, in a fresh
OS install running in a ppc64le host, this is the error
shown:
-
../configure --enable-trace-backend=simple --enable-debu
On 1 November 2017 at 19:31, Daniel Henrique Barboza
wrote:
> When executing 'configure' in a fresh QEMU clone, in a fresh
> OS install running in a ppc64le host, this is the error
> shown:
>
> -
>
> ../configure --enable-trace-backend=simple --enable-debug
> --target-list=ppc64-softmmu
>
On 11/01/2017 05:36 PM, Philippe Mathieu-Daudé wrote:
Maybe "configure: check $CC available before verifying host CPU" ?
If the maintainer is willing to amend the patch before pushing, works
for me!
Daniel
On 11/01/2017 04:31 PM, Daniel Henrique Barboza wrote:
When executing 'configur
On 11/01/2017 05:34 PM, Philippe Mathieu-Daudé wrote:
Hi Daniel,
On 11/01/2017 04:21 PM, Daniel Henrique Barboza wrote:
When executing 'configure' in a fresh QEMU clone, in a fresh
OS install running in a ppc64le host, this is the error
shown:
-
../configure --enable-trace-backend=simpl
Maybe "configure: check $CC available before verifying host CPU" ?
On 11/01/2017 04:31 PM, Daniel Henrique Barboza wrote:
> When executing 'configure' in a fresh QEMU clone, in a fresh
> OS install running in a ppc64le host, this is the error
> shown:
>
> -
>
> ../configure --enable-trace-ba
Hi Daniel,
On 11/01/2017 04:21 PM, Daniel Henrique Barboza wrote:
> When executing 'configure' in a fresh QEMU clone, in a fresh
> OS install running in a ppc64le host, this is the error
> shown:
>
> -
>
> ../configure --enable-trace-backend=simple --enable-debug
> --target-list=ppc64-so
The commit title/subject is misleading. I'll resend with a better commit
title.
On 11/01/2017 05:21 PM, Daniel Henrique Barboza wrote:
When executing 'configure' in a fresh QEMU clone, in a fresh
OS install running in a ppc64le host, this is the error
shown:
-
../configure --enable-trace-
When executing 'configure' in a fresh QEMU clone, in a fresh
OS install running in a ppc64le host, this is the error
shown:
-
../configure --enable-trace-backend=simple --enable-debug
--target-list=ppc64-softmmu
ERROR: Unsupported CPU = ppc64le, try --enable-tcg-interpreter
-
This
When executing 'configure' in a fresh QEMU clone, in a fresh
OS install running in a ppc64le host, this is the error
shown:
-
../configure --enable-trace-backend=simple --enable-debug
--target-list=ppc64-softmmu
ERROR: Unsupported CPU = ppc64le, try --enable-tcg-interpreter
-
This
Hi Francisco,
W dniu 01.11.2017 o 08:16, Francisco Iglesias pisze:
Add support for continuous read out of the RDSR and READ_FSR status
registers until the chip select is deasserted. This feature is supported
by amongst others 1 or more flashtypes manufactured by Numonyx (Micron),
Windbond, SST,
Ops, sorry about that. Resending
On 11/01/2017 05:10 PM, Daniel Henrique Barboza wrote:
When executing 'configure' in a fresh QEMU clone, in a fresh
OS install running in a ppc64le host, this is the error
shown:
-
../configure --enable-trace-backend=simple --enable-debug
--target
Hi,
This series failed build test on ppc host. Please find the details below.
Subject: [Qemu-devel] [PATCH v2] configure: adding ppc64le to supported host
CPUs
Type: series
Message-id: 20171101191030.16136-1-danie...@linux.vnet.ibm.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will
On 15/08/17 19:10, Richard Henderson wrote:
> [CC Peter re MemTxAttrs below]
>
> On 08/15/2017 09:38 AM, Mark Cave-Ayland wrote:
>> Working through an incorrect endian issue on qemu-system-sparc64, it has
>> become apparent that at least one OS makes use of the IE (Invert Endian)
>> bit in the SP
When executing 'configure' in a fresh QEMU clone, in a fresh
OS install running in a ppc64le host, this is the error
shown:
-
../configure --enable-trace-backend=simple --enable-debug
--target-list=ppc64-softmmu
ERROR: Unsupported CPU = ppc64le, try --enable-tcg-interpreter
-
This
On 11/01/2017 04:23 PM, Peter Maydell wrote:
On 1 November 2017 at 17:53, Daniel Henrique Barboza
wrote:
When executing 'configure' in a fresh QEMU clone, in a fresh
OS install running in a ppc64le host, this is the error
shown:
-
../configure --enable-trace-backend=simple --enable-debu
On 1 November 2017 at 17:53, Daniel Henrique Barboza
wrote:
> When executing 'configure' in a fresh QEMU clone, in a fresh
> OS install running in a ppc64le host, this is the error
> shown:
>
> -
>
> ../configure --enable-trace-backend=simple --enable-debug
> --target-list=ppc64-softmmu
>
On Wed, Nov 1, 2017 at 3:25 PM, Ross Lagerwall
wrote:
> Add /dev/fdset/ support to QIOChannelFile by calling qemu_open() instead
> of open() and qemu_close() instead of close(). There is a subtle
> semantic change since qemu_open() automatically sets O_CLOEXEC, but this
> doesn't affect any of the
On Wed, Nov 1, 2017 at 3:25 PM, Ross Lagerwall
wrote:
> If the file descriptor underlying QIOChannelFile is closed in the
> io_close() method, don't close it again in the finalize() method since
> the file descriptor number may have been reused in the meantime.
>
> Signed-off-by: Ross Lagerwall
When executing 'configure' in a fresh QEMU clone, in a fresh
OS install running in a ppc64le host, this is the error
shown:
-
../configure --enable-trace-backend=simple --enable-debug
--target-list=ppc64-softmmu
ERROR: Unsupported CPU = ppc64le, try --enable-tcg-interpreter
-
This
On 25.10.2017 11:34, Richard Henderson wrote:
> Primarily Emilio's work toward removing tb_lock, with fixes.
> But there are some other tcg-related patches that are queued.
>
> r~
>
> The following changes since commit 3d7196d43bfe12efe98568cb60057e273652b99b:
>
> Merge remote-tracking branch
Hi,
This series failed build test on s390x host. Please find the details below.
Type: series
Message-id: 20171031104813.3079.66585.stgit@pasha-VirtualBox
Subject: [Qemu-devel] [RFCPATCH06/20] replay: fix save/load vm for non-empty
queue
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script wil
Make scrolling in the monitor work.
Signed-off-by: John Arbuckle
---
ui/cocoa.m | 96 +-
1 file changed, 64 insertions(+), 32 deletions(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index 93e56d0518..744fa31a56 100644
--- a/ui/cocoa.m
+++ b/
The attached image is corrupted and QEMU doesn't handle it correctly.
Here are the fixes for this and other related problems:
https://lists.gnu.org/archive/html/qemu-block/2017-11/msg00010.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscri
COW (even empty/zero) areas require encryption too
Signed-off-by: Anton Nefedov
---
tests/qemu-iotests/134 | 9 +
tests/qemu-iotests/134.out | 10 ++
2 files changed, 19 insertions(+)
diff --git a/tests/qemu-iotests/134 b/tests/qemu-iotests/134
index 9914415..6083ae4 100755
From: Pavel Butsykin
Preallocated space in the image may remain unused; the patch adds
the functionality to identify and fix it in the qcow2_check
to avoid wasting storage space on the host.
Signed-off-by: Pavel Butsykin
Signed-off-by: Denis V. Lunev
Signed-off-by: Anton Nefedov
---
block/qc
Qcow2State and BlockDriverState flags have to be in sync
Signed-off-by: Anton Nefedov
---
block/qcow2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/qcow2.c b/block/qcow2.c
index 3899524..f41aaac 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -2184,6 +2184,7 @@ static int qcow2_i
Support the flag if the underlying BDS supports it
Signed-off-by: Anton Nefedov
Reviewed-by: Alberto Garcia
---
block/blkdebug.c | 3 ++-
block/blkverify.c | 2 +-
block/mirror.c | 2 +-
block/raw-format.c | 3 ++-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/block/blkd
To be used in the following commit without a forward declaration.
Signed-off-by: Anton Nefedov
---
block/qcow2.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 92cb9f9..db759ce 100644
--- a/block/qcow2
The idea is that ALLOCATE requests may overlap with other requests.
Reuse the existing block layer infrastructure for serialising requests.
Use the following approach:
- mark ALLOCATE serialising, so subsequent requests to the area wait
- ALLOCATE request itself must never wait if another reque
Signed-off-by: Anton Nefedov
---
tests/qemu-iotests/198 | 146 +
tests/qemu-iotests/198.out | 50
tests/qemu-iotests/group | 1 +
3 files changed, 197 insertions(+)
create mode 100755 tests/qemu-iotests/198
create mode 100644
Current write_zeroes implementation is good enough to satisfy this flag too
Signed-off-by: Anton Nefedov
Reviewed-by: Alberto Garcia
---
block/file-posix.c | 8
1 file changed, 8 insertions(+)
diff --git a/block/file-posix.c b/block/file-posix.c
index 36ee89e..c36e156 100644
--- a/blo
Signed-off-by: Anton Nefedov
Reviewed-by: Eric Blake
---
block/mirror.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/block/mirror.c b/block/mirror.c
index 307b639..19c8987 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -1064,6 +1064,11 @@ static void
bdrv_mirror_top_refresh_fil
if space preallocation feature is used, it can be detected that the space
is already zeroes, so COW can be skipped without additional zeroing of
the clusters.
Signed-off-by: Anton Nefedov
---
block/qcow2.h | 6 ++
block/qcow2-cluster.c | 2 ++
block/qcow2.c | 45 +++
From: "Denis V. Lunev"
This could be done after calculation of the end of data and metadata in
the qcow2 image.
Signed-off-by: Denis V. Lunev
Signed-off-by: Anton Nefedov
---
block/qcow2.h | 3 +++
block/qcow2-cluster.c | 9 +
block/qcow2-refcount.c | 7 +++
block/qcow2.
The flag is supposed to indicate that the region of the disk image has
to be sufficiently allocated so it reads as zeroes.
The call with the flag set must return -ENOTSUP if allocation cannot
be done efficiently.
This has to be made sure of by both
- the drivers that support the flag
- and the
Misc qcow2 corruption checks
This series contains a few checks that prevent QEMU from crashing
under some scenarios with corrupted qcow2 images.
The first patch solves the crash reported here:
https://bugs.launchpad.net/qemu/+bug/1728615
And the others solve similar crashes that I detected in
From: "Denis V. Lunev"
This patch adds image preallocation at expand to provide better locality
of QCOW2 image file and optimize this procedure for some distributed
storage where this procedure is slow.
Preallocation is not issued upon writing metadata clusters.
Possible conflicts are resolved
Signed-off-by: Anton Nefedov
---
block/blkverify.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/block/blkverify.c b/block/blkverify.c
index 06369f9..9ba65d0 100644
--- a/block/blkverify.c
+++ b/block/blkverify.c
@@ -140,6 +140,15 @@ static int blkverify_open(BlockDriverState *bs,
Each entry in the qcow2 cache contains an offset field indicating the
location of the data in the qcow2 image. If the offset is 0 then it
means that the entry contains no data and is available to be used when
needed.
Because of that it is not possible to store in the cache the first
cluster of the
qcow2_do_open() is checking that header.refcount_table_clusters is not
too large, but it doesn't check that it's greater than zero. Apart
from the fact that an image like that is obviously corrupted, trying
to use it crashes QEMU since we end up with a null s->refcount_table
after qcow2_refcount_in
If COW areas of the newly allocated clusters are zeroes on the backing image,
efficient bdrv_write_zeroes(flags=BDRV_REQ_ALLOCATE) can be used on the whole
cluster instead of writing explicit zero buffers later in perform_cow().
iotest 060:
write to the discarded cluster does not trigger COW anymo
This patch adds a simple iotests in which we try to write to an image
with an empty refcount table (i.e. with all entries set to 0).
This scenario was already handled by the existing consistency checks,
but we add an explicit test case for completeness.
Signed-off-by: Alberto Garcia
---
tests/q
v5: rebased, patches slightly reordered;
cluster allocation (to avoid writing zero-buffers)
now goes before an optional ahead preallocation
v4: http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg00109.html
This pull request is to improve a few performance problems of qcow2 format:
If the refcount data is corrupted then we can end up trying to
allocate a new L2 table at offset 0 in the image, triggering an
assertion in the qcow2 cache that would crash QEMU:
qcow2_cache_entry_mark_dirty: Assertion `c->entries[i].offset != 0' failed
This patch adds an explicit check for thi
Add an assert here to make last length assignment meaningful and
following return without tail dropping obvious.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
nbd/server.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/nbd/server.c b/nbd/server.c
index 7fcec0af7e..bcf0cdb47c 100644
--- a/
namelen should be here, lenght is unrelated.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
nbd/server.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/nbd/server.c b/nbd/server.c
index 70b40ed27e..7fcec0af7e 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -433,7 +433,7 @@
On Wed, Nov 01, 2017 at 02:48:17PM +, Nawrocki, Michael wrote:
> On 10/31/17, 13:50, "Dr. David Alan Gilbert" wrote:
>
> * Mike Nawrocki (michael.nawro...@gtri.gatech.edu) wrote:
> > Signed-off-by: Mike Nawrocki
> > ---
> > hw/net/eepro100.c| 2 +-
> > hw/pci/pci.c
> On 11/01/2017 12:25 PM, Dan Williams wrote:
[..]
>> It's not persistent memory if it requires a hypercall to make it
>> persistent. Unless memory writes can be made durable purely with cpu
>> instructions it's dangerous for it to be treated as a PMEM range.
>> Consider a guest that tried to map i
> On Oct 31, 2017, at 10:52 AM, Peter Maydell wrote:
>
> On 31 October 2017 at 14:38, Peter Maydell wrote:
>> On 5 October 2017 at 15:55, John Arbuckle wrote:
>>> Send control-alt key combinations to the guest if not used by the user
>>> interface.
>>>
>>> ---
>>> v2 changes:
>>> - changed l
On 10/31/17, 13:00, "Peter Maydell" wrote:
On 31 October 2017 at 15:44, Mike Nawrocki
wrote:
> This patch set does a few things. First, it switches the AMD CFI flash
MMIO
> operations from the old MMIO API to the new one. Second, it enables 8-byte
> wide flash arrays. Final
On 10/31/17, 13:50, "Dr. David Alan Gilbert" wrote:
* Mike Nawrocki (michael.nawro...@gtri.gatech.edu) wrote:
> Signed-off-by: Mike Nawrocki
> ---
> hw/net/eepro100.c| 2 +-
> hw/pci/pci.c | 2 ++
> include/hw/pci/pci.h | 1 +
> qemu-options.hx | 2 +
Add /dev/fdset/ support to QIOChannelFile by calling qemu_open() instead
of open() and qemu_close() instead of close(). There is a subtle
semantic change since qemu_open() automatically sets O_CLOEXEC, but this
doesn't affect any of the users of the function.
Signed-off-by: Ross Lagerwall
---
Cha
The code wrongly passes the mode to open() only if O_WRONLY is set.
Instead, the mode should be passed when O_CREAT is set (or O_TMPFILE on
Linux). Fix this by always passing the mode since open() will correctly
ignore the mode if it is not needed. Add a testcase which exercises this
bug and also c
Hi,
Here is a bug fix with the use of QIOChannelFile and 2 bug fixes and an
improvement to implementation of QIOChannelFile.
Regards,
Ross Lagerwall
Ross Lagerwall (4):
migration: Don't leak IO channels
io: Fix QIOChannelFile when creating and opening read-write
io: Don't call close multip
Since qemu_fopen_channel_{in,out}put take references on the underlying
IO channels, make sure to release our references to them.
Signed-off-by: Ross Lagerwall
---
New in v2.
migration/savevm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index 4a
If the file descriptor underlying QIOChannelFile is closed in the
io_close() method, don't close it again in the finalize() method since
the file descriptor number may have been reused in the meantime.
Signed-off-by: Ross Lagerwall
---
New in v2.
io/channel-file.c | 1 +
1 file changed, 1 inser
** Tags removed: verification-needed-zesty
** Tags added: verification-done-zesty
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719196
Title:
[arm64 ocata] newly created instances are unable to ra
Hi,
I'm trying to implement a buslogic scsi adapter (BT-958) for qemu. As a
basis I use its implementations in virtualbox.
At the moment, it is possible to send commands and data through the ports.
It is also possible to read data from kernel memory (mailboxes).
The current problem is that I can no
Hi David:
yes, with the same qemu, centos 7.2 guest cache is writeback and
none, the disk io almost, writeback feeling no effect.
but 7.1/7.3/7.4 cache is writeback was significantly faster than
none model
On Wed, Nov 1, 2017 at 8:02 PM, Paul Schlacter wrote:
> Hi David:
> yes,
On Wed 01 Nov 2017 09:55:21 AM CET, Alberto Garcia wrote:
> On Wed 01 Nov 2017 07:13:08 AM CET, Thomas Huth wrote:
>> On 30.10.2017 15:43, R.Nageswara Sastry wrote:
>>> Public bug reported:
>>>
>>> git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4
>>> This is on ppc64le architecture.
>>>
>>
Why?
Also I think this breaks the pointer in case window size doesn't match
surface size.
cheers,
Gerd
Why?
> ---
> ui/sdl2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ui/sdl2.c b/ui/sdl2.c
> index 685e4fabec..fa54353430 100644
> --- a/ui/sdl2.c
> +++ b/ui/sdl2.c
> @@ -349,7 +349,7 @@ static void handle_keydown(SDL_Event *ev)
> }
> gui_key_modifier_pressed
** Changed in: qemu
Assignee: Denys Zagorui (dzagorui) => (unassigned)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719339
Title:
serial8250: too much work for irq3
Status in QEMU:
In Pro
On Mon, 2017-10-23 at 23:07 +0200, Jindrich Makovicka wrote:
> ---
> ui/sdl2.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/ui/sdl2.c b/ui/sdl2.c
> index 7f51933234..aa37b39547 100644
> --- a/ui/sdl2.c
> +++ b/ui/sdl2.c
> @@ -566,9 +566,13 @@ static void han
On Mon, 2017-10-23 at 23:07 +0200, Jindrich Makovicka wrote:
> With SDL 2.0.6, calling SDL_ShowWindow during SDL_WINDOWEVENT_HIDDEN
> blocks all subsequent display updates.
Hmm, yes, seems we confuse SDL that way. Also not letting the user
hide the window isn't very nice (same for the _SHOWN even
On 11/01/2017 10:04 AM, Daniel P. Berrange wrote:
On Tue, Oct 31, 2017 at 04:09:02PM +, Ross Lagerwall wrote:
The code wrongly passes the mode to open() only if O_WRONLY is set.
Instead, the mode should be passed when O_CREAT is set (or O_TMPFILE on
Linux). Fix this by always passing the mod
On Tue, Oct 31, 2017 at 04:09:02PM +, Ross Lagerwall wrote:
> The code wrongly passes the mode to open() only if O_WRONLY is set.
> Instead, the mode should be passed when O_CREAT is set (or O_TMPFILE on
> Linux). Fix this by always passing the mode since open() will correctly
> ignore the mode
On Wed, Nov 01, 2017 at 08:58:32AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > No one confirmed whether or not this new field needs to be added to
> > the
> > VMSTATE sections, and if so, how todo this in a back compatible
> > manner
>
> Good question. Sky isn't falling if we don't send this o
* Paul Schlacter (wlfigh...@gmail.com) wrote:
> qemu version: 2.9.0
> image: centos 7.2 1511 raw
> cache mode: writeback
>
>
> In centos7.2 time, the use of writeback and none, the result of dd disk is
> the same io, no change
>
> But I replaced centos7.1 centos7.3 centos7.4 when writeback was
On Wed 01 Nov 2017 07:13:08 AM CET, Thomas Huth wrote:
> On 30.10.2017 15:43, R.Nageswara Sastry wrote:
>> Public bug reported:
>>
>> git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4
>> This is on ppc64le architecture.
>>
>> Re-production steps:
>>
>> 1. Copy the attached files named back
Hi,
> No one confirmed whether or not this new field needs to be added to
> the
> VMSTATE sections, and if so, how todo this in a back compatible
> manner
Good question. Sky isn't falling if we don't send this over, worst
case is a minor keyboard glitch, affecting only the SysRq key, right
qemu version: 2.9.0
image: centos 7.2 1511 raw
cache mode: writeback
In centos7.2 time, the use of writeback and none, the result of dd disk is
the same io, no change
But I replaced centos7.1 centos7.3 centos7.4 when writeback was
significantly faster than none
Would like to ask what is going
1 - 100 of 116 matches
Mail list logo
