The significand is passed to normalizeRoundAndPackFloat128() as high
first, low second. The current code passes the integer first, so the
result is incorrectly shifted left by 64 bits.
This bug affects the emulation of s390x instruction CXLGBR (convert
from logical 64-bit binary-integer operand to
Hi all,
I booted two sr-iov guests using KVM-VFIO and pinged each other with
no-load one night. I found that most of the latency was little than 0.1ms,
but several icmp_seq greater than 10ms, even up to 1000ms;
root@test-ping01:~# grep "time=[0-9][0-9]" outputfile
Mon May 7 23:05:12 201864 b
On Thu, 05/10 09:50, Stefan Hajnoczi wrote:
> On Wed, May 09, 2018 at 10:58:10PM +0800, Fam Zheng wrote:
> > +static off_t copy_file_range(int in_fd, off_t *in_off, int out_fd,
> > + off_t *out_off, size_t len, unsigned int
> > flags)
> > +{
> > +#ifdef __NR_copy_file_r
>
>
>
>
>Sent: Friday, May 11, 2018 at 5:08 AM
>From: "Murilo Opsfelder Araujo"
>To: junyan...@gmx.com
>Cc: "Haozhong Zhang" , xiaoguangrong.e...@gmail.com,
>crosthwaite.pe...@gmail.com, m...@redhat.com, qemu-devel@nongnu.org,
>dgilb...@redhat.com, quint...@redhat.com, "Junyan He" ,
>stefa...
On Fri, 11 May 2018 09:10:52 +0200
Petr Tesarik wrote:
> The significand is passed to normalizeRoundAndPackFloat128() as high
> first, low second. The current code passes the integer first, so the
> result is incorrectly shifted left by 64 bits.
>
> This bug affects the emulation of s390x instru
On 10.05.2018 15:32, Igor Mammedov wrote:
> On Thu, 10 May 2018 15:20:55 +0200
> David Hildenbrand wrote:
>
>> On 10.05.2018 15:02, Igor Mammedov wrote:
>>> On Wed, 9 May 2018 16:13:14 +0200
>>> David Hildenbrand wrote:
>>>
On 03.05.2018 17:49, David Hildenbrand wrote:
> Hotplug ha
Richard Henderson writes:
> The new function assumes that the input is an SNaN and
> does not double-check.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alex Bennée
> ---
> fpu/softfloat-specialize.h | 174 +
> include/fpu/softfloat.h| 5 ++
>
Richard Henderson writes:
> We want to be able to specialize on the canonical representation.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alex Bennée
> ---
> fpu/softfloat.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/fpu/softfloat.c
On Fri, May 11, 2018 at 12:37 AM, Steffen Görtz
wrote:
> my name is Steffen. I am a master candidate in electrical engineering at
> RWTH University in Aachen, Germany.
> Together with Julia Suvorova i will work on Cortex-M0 / BBC micro:bit
> support in QEMU this summer. This endeavor will supervis
Commit 2858ab09e6f708e381fc1a1cc87e747a690c4884 changed
PS/2 keyboard/mouse buffers to the standard size. However, its state
may change when migrating from the old buffer size and therefore irq needs
updating. But this change made wrong, because it throws the whole queue
if there are too much data
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180507123014.c67be381...@moya.office.hostfission.com
Subject: [Qemu-devel] (resend)[PATCH 1/2] ps2: Clear the queue on PS/2 mouse
reset and obey device disable
=== TEST SC
> From: Ciro Santilli [mailto:ciro.santi...@gmail.com]
> Did you manage to reproduce and solve the savevm and loadvm problems I
> mentioned at:
> http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg05219.html
> ?
I've tried to debug your scenario and found a bug in saving/loading PS/2
key
Ubuntu task is not actionable until we settled on how to change the
parsing code for long strings upstream, so I set it to confirmed but
wishlist (until we know what size a patch - or actions a recommendation
on handling differently has).
** Changed in: qemu (Ubuntu)
Status: New => Confirme
As Daniel asked in [1] making this abug report against Qemu (upstream).
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1568939
** Bug watch added: Red Hat Bugzilla #1568939
https://bugzilla.redhat.com/show_bug.cgi?id=1568939
** Also affects: qemu
Importance: Undecided
Status: New
The patch makes possible to avoid introducing dummy empty types
for the flat union branches that have no data.
Signed-off-by: Anton Nefedov
---
scripts/qapi/common.py | 18 --
scripts/qapi/doc.py| 2 +-
scripts/qapi/types.py | 2 +-
scripts/qapi/vis
the patch provides an example of a previously introduced data-partial
qapi union tag
Signed-off-by: Anton Nefedov
---
qapi/misc.json | 48
cpus.c | 2 --
2 files changed, 4 insertions(+), 46 deletions(-)
diff --git a/qapi/misc.json b/qap
hej,
inspired by this thread
http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg04802.html
Seems that nobody got around to this since (did anybody?),
so I thought I'd give a try.
There's a generator patch and usage example.
Anton Nefedov (2):
qapi: allow flat unions with empty branche
On 09/05/2018 17:06, Michael Walle wrote:
>>
>> All these calls into lm32_pic.c need to take the BQL. They are all
>> wrong, but this one was unlucky (or lucky) enough to be caught.
>>
>> Paolo
>
> my patch [1] from the beginning of this year just take the lock in
> op_helper.c.
Yes, I agree tha
On 11/05/2018 10:16, Pavel Dovgalyuk wrote:
> Commit 2858ab09e6f708e381fc1a1cc87e747a690c4884 changed
> PS/2 keyboard/mouse buffers to the standard size. However, its state
> may change when migrating from the old buffer size and therefore irq needs
> updating. But this change made wrong, because i
On 04/25/2018 03:05 PM, Gerd Hoffmann wrote:
On Mon, Apr 23, 2018 at 11:31:34AM +0200, KONRAD Frederic wrote:
On 04/19/2018 03:10 PM, Gerd Hoffmann wrote:
If some event caused some larger playback hickup the fine-grained timer
adjust isn't able to recover. Use a buffer overruns and underru
On 5 November 2015 at 12:13, Paolo Bonzini wrote:
> From: Pavel Dovgalyuk
>
> This patch adds functions to perform read and write operations
> with replay log.
>
> Reviewed-by: Paolo Bonzini
> +void replay_put_byte(uint8_t byte)
> +{
> +if (replay_file) {
> +putc(byte, replay_file);
On 11/05/2018 11:27, Peter Maydell wrote:
>> +uint8_t replay_get_byte(void)
>> +{
>> +uint8_t byte = 0;
>> +if (replay_file) {
>> +byte = getc(replay_file);
>> +}
>> +return byte;
>> +}
> Coverity (CID 1390576) points out that this function isn't checking
> the error return
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> On 11/05/2018 11:27, Peter Maydell wrote:
> >> +uint8_t replay_get_byte(void)
> >> +{
> >> +uint8_t byte = 0;
> >> +if (replay_file) {
> >> +byte = getc(replay_file);
> >> +}
> >> +return byte;
> >> +}
> > Coverity (CID 13
Rechecked in my site, the new installer (20180430) had solved the 1st
problem, but it leads to another problem: When uninstall QEMU, the
loaders.cache file cannot be deleted automatically.
For 2nd warning, I checked it again, when I choosed fully installing,
the icons are displayed correctly; But
On 10/05/2018 16:38, Peter Maydell wrote:
> On 10 May 2018 at 15:36, Richard Henderson wrote:
>> On 05/10/2018 06:00 AM, Peter Maydell wrote:
>>> Usually the logging of the CPU state produced by -d cpu is sufficient
>>> to diagnose problems, but sometimes you want to see the state of
>>> the float
On 9 May 2018 at 11:20, Michael Clark wrote:
> The following changes since commit c8b7e627b4269a3bc3ae41d9f420547a47e6d9b9:
>
> Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2018-05-04' into
> staging (2018-05-04 14:42:46 +0100)
>
> are available in the git repository at:
>
> http
Le 11/05/2018 à 02:43, Richard Henderson a écrit :
> Cc: Laurent Vivier
> Signed-off-by: Richard Henderson
> ---
> target/m68k/softfloat.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Laurent Vivier
On 05/10/2018 03:10 PM, Tony Krowiak wrote:
If I did not. I think this is a big problem. We need to at least
zeroize the queues (e.g. on system reset) to avoid leaking
sensitive information. Without this, there is no sane way to use
ap-passthrough. Or am I wrong?
I do not have a definitive a
On 10 May 2018 at 21:59, Laurent Vivier wrote:
> This is a follow up
> of patch:
>
> commit c2e3dee6e03527baf8698698cce76b1a3174969a
> Author: Laurent Vivier
> Date: Sun Feb 13 23:37:34 2011 +0100
>
> linux-user: Define target alignment size
>
> In my case m6
> This says what the patch does, but not why. What is the actual use case
> scenario where changing semantics to have the qcow2 overwrite the
> garbage to read 0 instead of any pre-existing garbage, when dealing with
> portions of the disk that have not yet been written by the guest? Are
> you tr
On 8 May 2018 at 21:42, Laurent Vivier wrote:
> Le 08/05/2018 à 20:55, Richard Henderson a écrit :
>> Fedora 28 ships with the released gcc 8.
>>
>> The Werror stems from the compiler finding a path through the second
>> switch via a missing default case in which src1 is uninitialized, and
>> not
On 10 May 2018 at 23:26, Laurent Vivier wrote:
> Values defined for sparc are not correct.
> Copy the content of "arch/sparc/include/uapi/asm/socket.h"
> to fix them.
>
> Signed-off-by: Laurent Vivier
> ---
> linux-user/sparc/sockbits.h | 161
>
> 1
v4: - Fix raw offset and size. [Eric]
- iscsi: Drop unnecessary return values and variables in favor of
constants. [Stefan]
- qcow2: Handle small backing case. [Stefan]
- file-posix: Translate ENOSYS to ENOTSUP. [Stefan]
- API documentation and commit message. [Stefan]
- A
We don't verify the request range against s->size in the I/O callbacks
except for raw_co_pwritev. This is wrong (especially for
raw_co_pwrite_zeroes and raw_co_pdiscard), so fix them.
Signed-off-by: Fam Zheng
---
block/raw-format.c | 63 --
1 f
Introduce the bdrv_co_copy_range() API for copy offloading. Block
drivers implementing this API support efficient copy operations that
avoid reading each block from the source device and writing it to the
destination devices. Examples of copy offload primitives are SCSI
EXTENDED COPY and Linux co
The two callbacks are implemented quite similarly to the read/write
functions: bdrv_co_copy_range_from maps for read and calls into bs->file
or bs->backing depending on the allocation status; bdrv_co_copy_range_to
maps for write and calls into bs->file.
Signed-off-by: Fam Zheng
---
block/qcow2.c
On 10 May 2018 at 23:25, Laurent Vivier wrote:
> No code change.
>
> Signed-off-by: Laurent Vivier
> ---
Reviewed-by: Peter Maydell
> +#if 0
> +/* To add: Allow local address and port reuse. */
> +#define TARGET_SO_REUSEPORT 0x0200
> +#endif
As a follow-on cleanup, we might as well fix up the
With copy_file_range(2), we can implement the bdrv_co_copy_range
semantics.
Signed-off-by: Fam Zheng
---
block/file-posix.c | 96 +++--
include/block/raw-aio.h | 10 --
2 files changed, 101 insertions(+), 5 deletions(-)
diff --git a/block/fil
Just pass down to ->file.
Signed-off-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
---
block/raw-format.c | 32
1 file changed, 32 insertions(+)
diff --git a/block/raw-format.c b/block/raw-format.c
index 803083f1a1..71ca9c627d 100644
--- a/block/raw-format.c
+++ b
The device designator data returned in INQUIRY command will be useful to
fill in source/target fields during copy offloading. Do this when
connecting to the target and save the data for later use.
Signed-off-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
---
block/iscsi.c| 41 ++
On 10 May 2018 at 23:25, Laurent Vivier wrote:
> No code change.
>
> Signed-off-by: Laurent Vivier
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
Issue EXTENDED COPY (LID1) command to implement the copy_range API.
The parameter data construction code is modified from libiscsi's
iscsi-dd.c.
Signed-off-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
---
block/iscsi.c| 219 +++
include/scs
This loop is repeated a growing number times. Make a helper.
Signed-off-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
block/iscsi.c | 54 +-
1 file changed, 17 insertions(+), 37 deletions(-)
diff --git a/block/iscsi.
On 10 May 2018 at 23:25, Laurent Vivier wrote:
> No code change.
>
> Signed-off-by: Laurent Vivier
Reviewed-by: Peter Maydell
thanks
-- PMM
It's a BlockBackend wrapper of the BDS interface.
Signed-off-by: Fam Zheng
Reviewed-by: Stefan Hajnoczi
---
block/block-backend.c | 18 ++
include/sysemu/block-backend.h | 4
2 files changed, 22 insertions(+)
diff --git a/block/block-backend.c b/block/block-backe
On 10 May 2018 at 23:26, Laurent Vivier wrote:
> No code change.
>
> Signed-off-by: Laurent Vivier
> ---
> --- a/linux-user/socket.h
> +++ b/linux-user/socket.h
> @@ -1,6 +1,6 @@
>
> #if defined(TARGET_MIPS) || defined(TARGET_HPPA) || defined(TARGET_ALPHA) ||
> \
> -defined(TARGET_SPARC)
>
The new blk_co_copy_range interface offers a more efficient way in the
case of network based storage. Make use of it to allow faster convert
operation.
Since copy offloading cannot do zero detection ('-S') and compression
(-c), only try it when these options are not used.
Signed-off-by: Fam Zheng
On 10 May 2018 at 23:26, Laurent Vivier wrote:
> No code change.
>
> Signed-off-by: Laurent Vivier
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
On 10/05/2018 15:10, Tony Krowiak wrote:
On 05/09/2018 10:28 AM, Halil Pasic wrote:
On 05/08/2018 02:25 PM, Tony Krowiak wrote:
Introduces a VFIO based AP device. The device is defined via
the QEMU command line by specifying:
-device vfio-ap,sysfsdev=
There may be only one vfio-ap devi
On 09/05/2018 17:48, Cornelia Huck wrote:
The vfio-ccw code will need this, and it matches treatment of ssch
and csch.
Signed-off-by: Cornelia Huck
---
drivers/s390/cio/ioasm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/s390/cio/ioasm.c b/drivers/s390/cio/ioasm.c
index 14d32
On 09/05/2018 17:48, Cornelia Huck wrote:
Currently, vfio-ccw only relays start subchannel requests to the real
hardware, which is enough in many cases but falls short e.g. during
error recovery.
Fortunately, it is easy to add support for halt and clear subchannel
requests to the existing infras
On 09/05/2018 17:49, Cornelia Huck wrote:
The initial version of vfio-ccw did not support forwarding of the
halt or clear functions to the device, and we had to emulate them
instead.
For versions of the vfio-ccw kernel implementation that indeed do
support halt/clear (by indicating them in the f
On 8 May 2018 at 23:14, Paolo Bonzini wrote:
> The following changes since commit cc8f8ba754bba17eea9791d67b572eb26e30b4ce:
>
> Merge remote-tracking branch
> 'remotes/ehabkost/tags/machine-next-pull-request' into staging (2018-05-08
> 15:25:17 +0100)
>
> are available in the git repository at
On 11/05/2018 14:19, Peter Maydell wrote:
> Some of my build setups barf on the new glib version requirement:
>
> * my aarch64 build host (a gcc compile farm machine which is running
>Ubuntu 14.04.5 LTS and has glib 2.40.2)
> * my windows cross compile setups (which have glib 2.34.3)
>
> Th
I have the same issue. When I open the task manager on the virtualized Windows
10 VM I see the HDD time is at 100% but the data transfer rate is actual 0b/s.
I've tried any combination of the options below and the issue was always
reproducible with qemu-2.12.0-1 and never with qemu-2.11.1-2.
Li
The following changes since commit cc8f8ba754bba17eea9791d67b572eb26e30b4ce:
Merge remote-tracking branch
'remotes/ehabkost/tags/machine-next-pull-request' into staging (2018-05-08
15:25:17 +0100)
are available in the git repository at:
git://github.com/bonzini/qemu.git tags/for-upstream
Create a qcow2 directly on bare block device with
"-o preallocation=metadata" option. When read this qcow2, it will
return pre-existing data on block device, and this may lead to
data leakage. This patch add QCOW_OFLAG_ZERO for all preallocated
l2 entry to avoid this problem.
Signed-off-by: Ivan R
On 11 May 2018 at 13:33, Paolo Bonzini wrote:
> On 11/05/2018 14:19, Peter Maydell wrote:
>> Some of my build setups barf on the new glib version requirement:
>>
>> * my aarch64 build host (a gcc compile farm machine which is running
>>Ubuntu 14.04.5 LTS and has glib 2.40.2)
>> * my windows
On 11 May 2018 at 08:10, Petr Tesarik wrote:
> The significand is passed to normalizeRoundAndPackFloat128() as high
> first, low second. The current code passes the integer first, so the
> result is incorrectly shifted left by 64 bits.
>
> This bug affects the emulation of s390x instruction CXLGBR
On Fri, May 11, 2018 at 01:19:51PM +0100, Peter Maydell wrote:
> On 8 May 2018 at 23:14, Paolo Bonzini wrote:
> > The following changes since commit cc8f8ba754bba17eea9791d67b572eb26e30b4ce:
> >
> > Merge remote-tracking branch
> > 'remotes/ehabkost/tags/machine-next-pull-request' into staging
On 11 May 2018 at 13:42, Daniel P. Berrangé wrote:
> On Fri, May 11, 2018 at 01:19:51PM +0100, Peter Maydell wrote:
>> Some of my build setups barf on the new glib version requirement:
>>
>> * my aarch64 build host (a gcc compile farm machine which is running
>>Ubuntu 14.04.5 LTS and has glib
On Fri, May 11, 2018 at 01:50:28PM +0100, Peter Maydell wrote:
> On 11 May 2018 at 13:42, Daniel P. Berrangé wrote:
> > On Fri, May 11, 2018 at 01:19:51PM +0100, Peter Maydell wrote:
> >> Some of my build setups barf on the new glib version requirement:
> >>
> >> * my aarch64 build host (a gcc co
This is an alternative implementation of "MemoryDevice: introduce and use
ResourceHandler". It is based on the proposal of Igor, to have multi stage
hotplug handlers. This seems to work just fine for DIMMs and virtio-mem.
This approach results in slightly more LOC (each machine has to
implement su
The start of the address space does not have to be aligned for the
search. Handly this case explicitly when starting the search for a new
address.
Signed-off-by: David Hildenbrand
---
hw/mem/memory-device.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/mem/memory-devic
From: Igor Mammedov
it will allow to return another hotplug handler than the default
one for a specific bus based device type. Which is needed to handle
non trivial plug/unplug sequences that need the access to resources
configured outside of bus where device is attached.
That will allow for ret
Let's handle it via hotplug_handler_unplug().
Signed-off-by: David Hildenbrand
---
hw/ppc/spapr.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 7881565d41..2df15f9db6 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -34
For multi stage hotplug handlers, we'll have to do some error handling
in some hotplug functions, so let's use a local error variable (except
for unplug requests).
Also, add code to pass control to the final stage hotplug handler at the
parent bus.
Signed-off-by: David Hildenbrand
---
hw/ppc/sp
Implement the new functions, we don't have to care about alignment for
these DIMMs right now, so leave that function unimplemented.
Signed-off-by: David Hildenbrand
---
hw/mem/pc-dimm.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
ind
For multi stage hotplug handlers, we'll have to do some error handling
in some hotplug functions, so let's use a local error variable (except
for unplug requests).
Also, add code to pass control to the final stage hotplug handler at the
parent bus.
Signed-off-by: David Hildenbrand
---
hw/i386/p
Let's handle it via hotplug_handler_unplug(). E.g. necessary to hotplug/
unplug memory devices (which a pc-dimm is) later.
Signed-off-by: David Hildenbrand
---
hw/ppc/spapr.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spap
Necessary to hotplug them cleanly later. We can only support memory
devices that are not DIMMs if we have a parent bus. Otherwise we might
miss "Device '%s' can not be hotplugged on this machine" cases.
Signed-off-by: David Hildenbrand
---
hw/i386/pc.c | 7 +++
1 file changed, 7 insertions(+
We will need a handful of new functions:
- set_addr(): To set the calculated address
- get_memory_region(): To add it to the memory region container
- get_addr(): If the device has any specific alignment requirements
Using these and the existing functions, we can properly plug/unplug
memory device
On s390x, we sometimes have to shrink ram_size in order to be able to
correctly indicate the size to the guest.
In case maxmem is not set, ram_size and maxram_size should always be
kept equal. Make sure to also fixup maxram_size if necessary.
In case maxmem is set, we really want to bail out in c
Necessary to hotplug them cleanly later. We can only support memory
devices that are not DIMMs if we have a parent bus. Otherwise we might
miss "Device '%s' can not be hotplugged on this machine" cases.
Signed-off-by: David Hildenbrand
---
hw/ppc/spapr.c | 7 +++
1 file changed, 7 insertions
Let's move the plug logic into the applicable hotplug handler for pc and
spapr.
Signed-off-by: David Hildenbrand
---
hw/i386/pc.c | 35 ---
hw/mem/memory-device.c | 40 ++--
hw/mem/pc-dimm.c
While s390x has no real interface for communicating devices mapped into
the physical address space of the guest, paravirtualized devices can
easily expose the applicable address range themselves.
So let's use the difference between maxram_size and ram_size as the size
for our hotplug memory area (
Let's move the unplug logic into the applicable hotplug handler for pc and
spapr.
We'll move the plug logic next, then this will look more symmetrical in
the hotplug handlers.
Signed-off-by: David Hildenbrand
---
hw/i386/pc.c | 17 -
hw/mem/memory-device.c
Let's move all pre-plug checks we can do without the device being
realized into the applicable hotplug handler for pc and spapr.
Signed-off-by: David Hildenbrand
---
hw/i386/pc.c | 11 +++
hw/mem/memory-device.c | 72 +++---
hw/pp
Let's route all memory devices we can hotplug through the machine hotplug
handler, just like on pc and spapr.
Signed-off-by: David Hildenbrand
---
default-configs/s390x-softmmu.mak | 1 +
hw/s390x/s390-virtio-ccw.c| 35 +++
2 files changed, 36 insertions(
For multi stage hotplug handlers, we'll have to do some error handling
in some hotplug functions, so let's use a local error variable (except
for unplug requests).
Also, add code to pass control to the final stage hotplug handler at the
parent bus.
Signed-off-by: David Hildenbrand
---
hw/s390x/
On 9 May 2018 at 12:23, Juan Quintela wrote:
> Hi
>
> this includes the reviewed patches for migration:
> - update docs (dave)
> - fixes for blocktime (text cleatups) (dave)
> - migration+tls (dave)
> - rdma index fix (lidong)
> - Postcopy recovery (peterx)
> - Parts reviewed of multifd and tests
On 05/11/2018 07:37 AM, Ivan Ren wrote:
Create a qcow2 directly on bare block device with
"-o preallocation=metadata" option. When read this qcow2, it will
return pre-existing data on block device, and this may lead to
data leakage. This patch add QCOW_OFLAG_ZERO for all preallocated
l2 entry to
(CCing Cleber and avocado-devel in case they have suggestions)
On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
[...]
> Ironically I have been using the Gumstix machines quite a lot for the SD
> 'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
> reach t
On 05/11/2018 07:08 AM, Fam Zheng wrote:
We don't verify the request range against s->size in the I/O callbacks
except for raw_co_pwritev. This is wrong (especially for
raw_co_pwrite_zeroes and raw_co_pdiscard), so fix them.
Did you bother identifying how long the bug has been present (but read
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 9 May 2018 at 12:23, Juan Quintela wrote:
> > Hi
> >
> > this includes the reviewed patches for migration:
> > - update docs (dave)
> > - fixes for blocktime (text cleatups) (dave)
> > - migration+tls (dave)
> > - rdma index fix (lidong)
> > -
On 11 May 2018 at 15:20, Dr. David Alan Gilbert wrote:
> I'd be tempted to drop 03/41 xbzrle test and see what happens;
> it's a heavy CPU eater so might be making things worse when in parallel.
> I suspect that aarch64 case is the same one we occasionally hit
> due to the page flag dirtying bein
On Fri, 11 May 2018 15:20:05 +0800
Zhu Yijun wrote:
> Hi all,
>
> I booted two sr-iov guests using KVM-VFIO and pinged each other with
> no-load one night. I found that most of the latency was little than 0.1ms,
> but several icmp_seq greater than 10ms, even up to 1000ms;
>
> root@test-ping
On Tue, May 08, 2018 at 03:02:07PM +, Moger, Babu wrote:
>
> > -Original Message-
> > From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> > Sent: Tuesday, May 8, 2018 9:17 AM
> > To: Moger, Babu
> > Cc: m...@redhat.com; mar...@redhat.com; pbonz...@redhat.com;
> > r...@twiddle.net; mt
On 05/11/2018 09:55 AM, Eduardo Habkost wrote:
> (CCing Cleber and avocado-devel in case they have suggestions)
>
> On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
> [...]
>> Ironically I have been using the Gumstix machines quite a lot for the SD
>> 'subsystem' refactor,
On Wed, May 09, 2018 at 04:36:29PM +0800, Liu Jingqi wrote:
> An initiator proximity domain (memory initiator) is any device
> such as a CPU or a separate memory I/O device that can initiate
> a memory request. A target proximity domain (memory target)
> is a CPU-accessible physical address range.
>> Create a qcow2 directly on bare block device with
>> "-o preallocation=metadata" option. When read this qcow2, it will
>> return pre-existing data on block device, and this may lead to
>> data leakage. This patch add QCOW_OFLAG_ZERO for all preallocated
>> l2 entry to avoid this problem.
>
> Thi
On 9 May 2018 at 16:48, Richard Henderson wrote:
> The following changes since commit e5cd695266c5709308aa95b1baae499e4b5d4544:
>
> Merge remote-tracking branch 'remotes/cody/tags/block-pull-request' into
> staging (2018-05-08 17:05:58 +0100)
>
> are available in the Git repository at:
>
> ht
On Wed, May 09, 2018 at 04:34:29PM +0800, Liu Jingqi wrote:
> HMAT is defined in ACPI 6.2: 5.2.27 Heterogeneous Memory Attribute Table
> (HMAT).
> The specification references below link:
> http://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf
>
> It describes the memory attributes, such
> -Original Message-
> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> Sent: Friday, May 11, 2018 9:12 AM
> To: Moger, Babu
> Cc: m...@redhat.com; mar...@redhat.com; pbonz...@redhat.com;
> r...@twiddle.net; mtosa...@redhat.com; ge...@hostfission.com;
> k...@tripleback.net; qemu-deve
On Fri, May 11, 2018 at 02:44:11PM +, Moger, Babu wrote:
>
>
> > -Original Message-
> > From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> > Sent: Friday, May 11, 2018 9:12 AM
> > To: Moger, Babu
> > Cc: m...@redhat.com; mar...@redhat.com; pbonz...@redhat.com;
> > r...@twiddle.net;
Alex Bennée writes:
> Richard Henderson writes:
>
>> The new function assumes that the input is an SNaN and
>> does not double-check.
>>
>> Signed-off-by: Richard Henderson
>
> Reviewed-by: Alex Bennée
but...but...
>> -float16 float16_maybe_silence_nan(float16 a_, float_status *status)
>> +
On 05/11/2018 08:06 AM, Alex Bennée wrote:
> but...but...
>>> -float16 float16_maybe_silence_nan(float16 a_, float_status *status)
>>> +
>>> +float16 float16_maybe_silence_nan(float16 a, float_status *status)
>>> {
>>> +if (float16_is_signaling_nan(a, status)) {
>>> +float16_silence_na
On 05/04/2018 03:37 AM, Igor Mammedov wrote:
New preconfig runstate will be used in follow up patches
related to introducing --preconfig CLI option and is
intended to replace prelaunch runstate from QEMU start
up to machine_init callback.
Signed-off-by: Igor Mammedov
---
qapi/run-state.json |
On 05/04/2018 03:37 AM, Igor Mammedov wrote:
Subject line is stale, needs to be updated to match new spelling...
New option will be used to allow commands, which are prepared/need
to run, during preconfig state. Other commands that should be able
to run in preconfig state, should be amended to
On 05/04/2018 03:37 AM, Igor Mammedov wrote:
use new allow-preconfig parameter in tests and make sure that
the QAPISchema can parse allow-preconfig correctly
Signed-off-by: Igor Mammedov
v7:
Missing --- separator to stop 'git am' from including the changelog.
* s/allowed_in_preconfig/all
1 - 100 of 278 matches
Mail list logo
