On 02/16/2017 03:51 PM, Janosch Frank wrote:
> While trying to fix a bug in the s390 migration code, I noticed that
> QEMU ignores practically all errors returned from that VM ioctl. QEMU
> behaves as specified in the KVM api and only processes -1 (-EPERM) as an
> error.
>
> Unfortunately the docu
> -Original Message-
> From: Qemu-devel [mailto:qemu-devel-bounces+yi.l.liu=intel@nongnu.org]
> On Behalf Of Peter Xu
> Sent: Monday, February 20, 2017 3:48 PM
> To: Alex Williamson
> Cc: Lan, Tianyu ; Tian, Kevin ;
> m...@redhat.com; jan.kis...@siemens.com; jasow...@redhat.com; qemu-
Hi,
Patch 1 fixes a double free bug, and patch 2 fixes a memory leak bug.
Patch 3 is an optimization for filter-rewriter.
Please review, thanks.
zhanghailiang (3):
net/colo: fix memory double free error
filter-rewriter: fix memory leak for connection in
connection_track_table
filter-re
While the offset of packets's sequence for primary side and
secondary side is zero, it is unnecessary to call net_checksum_calculate()
to recalculate the checksume value of packets.
Signed-off-by: zhanghailiang
---
net/filter-rewriter.c | 18 +++---
1 file changed, 11 insertions(+),
The 'primary_list' and 'secondary_list' members of struct Connection
is not allocated through dynamically g_queue_new(), but we free it by using
g_queue_free(), which will lead to a double-free bug.
Signed-off-by: zhanghailiang
---
net/colo.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/
After a net connection is closed, we didn't clear its releated resources
in connection_track_table, which will lead to memory leak.
Let't track the state of net connection, if it is closed, its related
resources will be cleared up.
Signed-off-by: zhanghailiang
---
net/colo.h| 4 +++
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Friday, February 17, 2017 2:43 PM
> To: Liu, Yi L ; Michael S. Tsirkin ;
> qemu-
> de...@nongnu.org
> Cc: Peter Maydell ; Eduardo Habkost
> ; Peter Xu ; Paolo Bonzini
> ; Richard Henderson ; Tian, Kevin
> ; Lan, T
On Mon, Feb 20, 2017 at 08:17:32AM +, Liu, Yi L wrote:
> > -Original Message-
> > From: Qemu-devel [mailto:qemu-devel-bounces+yi.l.liu=intel@nongnu.org]
> > On Behalf Of Peter Xu
> > Sent: Monday, February 20, 2017 3:48 PM
> > To: Alex Williamson
> > Cc: Lan, Tianyu ; Tian, Kevin ;
Am 2017-02-18 00:00, schrieb Philippe Mathieu-Daudé:
On 02/16/2017 02:26 PM, Peter Maydell wrote:
Don't truncate the multiplication and do a 64 bit one instead
because the result is stored in a 64 bit variable.
This fixes a similar coverity warning to commits 237a8650d640 and
4382fa655498, in a
> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Friday, February 17, 2017 3:00 PM
> To: Liu, Yi L
> Cc: Michael S. Tsirkin ; qemu-devel@nongnu.org; Peter
> Maydell ; Eduardo Habkost
> ; Jason Wang ; Paolo Bonzini
> ; Richard Henderson ; Tian, Kevin
> ; Lan, Tianyu
Philippe Mathieu-Daudé writes:
> Hi Alex,
>
> I first tried "make docker-image-debian-armhf-cross NOUSER=1 V=1"
> which worked fine, then "make docker-image-debian-armhf-cross
> NOUSER=0" but got a "Image is up to date." I thought I should have to
> remove the image manually so I typed "docker r
Philippe Mathieu-Daudé writes:
> On 02/16/2017 09:34 AM, Alex Bennée wrote:
>> This provides a basic Debian install with access to the emdebian cross
>> compilers. The debian-armhf-cross and debian-arm64-cross targets build
>> on the basic Debian image to allow cross compiling to those targets.
On 2017年02月20日 16:27, Liu, Yi L wrote:
-Original Message-
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Friday, February 17, 2017 2:43 PM
To: Liu, Yi L ; Michael S. Tsirkin ; qemu-
de...@nongnu.org
Cc: Peter Maydell ; Eduardo Habkost
; Peter Xu ; Paolo Bonzini
; Richard Henderson
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Monday, February 20, 2017 5:04 PM
> To: Liu, Yi L ; Michael S. Tsirkin ;
> qemu-
> de...@nongnu.org
> Cc: Lan, Tianyu ; Peter Maydell
> ; Tian, Kevin ; Eduardo
> Habkost ; Peter Xu ; Alex
> Williamson ; Paolo Bonz
** Changed in: qemu
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/741115
Title:
Add support of coprocessor cp15, cp14 registers exposion in the
embedded gdb s
On 2017年02月20日 17:13, Liu, Yi L wrote:
-Original Message-
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Monday, February 20, 2017 5:04 PM
To: Liu, Yi L ; Michael S. Tsirkin ; qemu-
de...@nongnu.org
Cc: Lan, Tianyu ; Peter Maydell
; Tian, Kevin ; Eduardo
Habkost ; Peter Xu ; Alex
W
Hi Paolo,
>
>
> On 16/02/2017 02:31, Gonglei (Arei) wrote:
> > And the below patch works for me, I can support max 255 vcpus for WS2012
> > with hyper-v enlightenments.
> >
> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> > index 27fd050..efe3cbc 100644
> > --- a/target/i386/kvm.c
> > ++
From: Paolo Bonzini
qcow2_create2 calls this. Do not run a nested event loop, as that
breaks when aio_co_wake tries to queue the coroutine on the co_queue_wakeup
list of the currently running one.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Message-id: 20
From: Paolo Bonzini
AioContext is fairly self contained, the only dependency is QEMUTimer but
that in turn doesn't need anything else. So move them out of block-obj-y
to avoid introducing a dependency from io/ to block-obj-y.
main-loop and its dependency iohandler also need to be moved, because
The following changes since commit 5dae13cd71f0755a1395b5a4cde635b8a6ee3f58:
Merge remote-tracking branch 'remotes/rth/tags/pull-or-20170214' into staging
(2017-02-14 09:55:48 +)
are available in the git repository at:
git://github.com/stefanha/qemu.git tags/block-pull-request
for you
From: Paolo Bonzini
In the client, read the reply headers from a coroutine, switching the
read side between the "read header" coroutine and the I/O coroutine that
reads the body of the reply.
In the server, if the server can read more requests it will create a new
"read request" coroutine as soo
From: Paolo Bonzini
Once the thread pool starts using aio_co_wake, it will also need
qemu_get_current_aio_context(). Make test-thread-pool create
an AioContext with qemu_init_main_loop, so that stubs/iothread.c
and tests/iothread.c can provide the rest.
Reviewed-by: Stefan Hajnoczi
Signed-off-
From: Paolo Bonzini
aio_co_wake provides the infrastructure to start a coroutine on a "home"
AioContext. It will be used by CoMutex and CoQueue, so that coroutines
don't jump from one context to another when they go to sleep on a
mutex or waitqueue. However, it can also be used as a more effici
From: Paolo Bonzini
The AioContext data structures are now protected by list_lock and/or
they are walked with FOREACH_RCU primitives. There is no need anymore
to acquire the AioContext for the entire duration of aio_dispatch.
Instead, just acquire it before and after invoking the callbacks.
The
From: Paolo Bonzini
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Reviewed-by: Daniel P. Berrange
Message-id: 20170213135235.12274-15-pbonz...@redhat.com
Signed-off-by: Stefan Hajnoczi
---
block/archipelago.c | 3 +++
block/blkreplay.c | 2 +-
bloc
From: Paolo Bonzini
This is in preparation for making qio_channel_yield work on
AioContexts other than the main one.
Reviewed-by: Daniel P. Berrange
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Message-id: 20170213135235.12274-6-pbonz...@redhat.com
Signed-
From: Paolo Bonzini
Support separate coroutines for reading and writing, and place the
read/write handlers on the AioContext that the QIOChannel is registered
with.
Reviewed-by: Daniel P. Berrange
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Message-id: 20
From: Paolo Bonzini
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Reviewed-by: Daniel P. Berrange
Message-id: 20170213135235.12274-13-pbonz...@redhat.com
Signed-off-by: Stefan Hajnoczi
---
block/qed.h | 3 +++
block/curl.c|
From: Paolo Bonzini
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Reviewed-by: Daniel P. Berrange
Message-id: 20170213135235.12274-16-pbonz...@redhat.com
Signed-off-by: Stefan Hajnoczi
---
block/archipelago.c| 3 ---
block/block-backend.c | 7 --
Sorry for forgetting the "no irrelevant change" rule...won't do that next time!
2017-02-20 14:09 GMT+08:00 Thomas Huth :
> On 19.02.2017 04:55, Philippe Mathieu-Daudé wrote:
>> On 02/17/2017 05:27 AM, Ziyue Yang wrote:
>>> From: Ziyue Yang
>>>
>>> Currently mon_get_cpu always dereferences first_c
From: Paolo Bonzini
This covers both file descriptor callbacks and polling callbacks,
since they execute related code.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Reviewed-by: Daniel P. Berrange
Message-id: 20170213135235.12274-14-pbonz...@redhat.com
Sign
From: Paolo Bonzini
As a small step towards the introduction of multiqueue, we want
coroutines to remain on the same AioContext that started them,
unless they are moved explicitly with e.g. aio_co_schedule. This patch
avoids that coroutines switch AioContext when they use a CoMutex.
For now it d
From: Paolo Bonzini
Pull the increment/decrement pair out of aio_bh_poll and into the
callers.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Reviewed-by: Daniel P. Berrange
Message-id: 20170213135235.12274-18-pbonz...@redhat.com
Signed-off-by: Stefan Hajnoc
From: Paolo Bonzini
qed_aio_start_io and qed_aio_next_io will not have to acquire/release
the AioContext, while qed_aio_next_io_cb will. Split the functionality
and gain a little type-safety in the process.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Revi
From: Paolo Bonzini
Keep the coroutine on the same AioContext. Without this change,
there would be a race between yielding the coroutine and reentering it.
While the race cannot happen now, because the code only runs from a single
AioContext, this will change with multiqueue support in the block
From: Paolo Bonzini
This adds a CoMutex around the existing CoQueue. Because the write-side
can just take CoMutex, the old "writer" field is not necessary anymore.
Instead of removing it altogether, count the number of pending writers
during a read-side critical section and forbid further reader
From: Paolo Bonzini
Running a very small critical section on pthread_mutex_t and CoMutex
shows that pthread_mutex_t is much faster because it doesn't actually
go to sleep. What happens is that the critical section is shorter
than the latency of entering the kernel and thus FUTEX_WAIT always
fail
From: Paolo Bonzini
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Reviewed-by: Daniel P. Berrange
Message-id: 20170213135235.12274-19-pbonz...@redhat.com
Signed-off-by: Stefan Hajnoczi
---
include/block/block_int.h | 64 +--
From: Paolo Bonzini
This will avoid forward references in the next patch. It is also
more logical because CoQueue is not anymore the basic primitive.
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Message-id: 20170213181244.16297-5-pbonz...@redhat.com
Signed-off-by: Stefan Hajnoczi
---
From: Paolo Bonzini
This patch prepares for the removal of unnecessary lockcnt inc/dec pairs.
Extract the dispatching loop for file descriptor handlers into a new
function aio_dispatch_handlers, and then inline aio_dispatch into
aio_poll.
aio_dispatch can now become void.
Reviewed-by: Stefan Ha
From: Paolo Bonzini
Add two implementations of the same benchmark as the previous patch,
but using pthreads. One uses a normal QemuMutex, the other is Linux
only and implements a fair mutex based on MCS locks and futexes.
This shows that the slower performance of the 5-thread case is due to
the
* Christian Borntraeger (borntrae...@de.ibm.com) wrote:
> On 02/16/2017 03:51 PM, Janosch Frank wrote:
> > While trying to fix a bug in the s390 migration code, I noticed that
> > QEMU ignores practically all errors returned from that VM ioctl. QEMU
> > behaves as specified in the KVM api and only
On Fri, Feb 17, 2017 at 04:42:15PM -0500, Jeff Cody wrote:
> On Thu, Feb 16, 2017 at 02:24:19PM -0800, ashish mittal wrote:
> > Hi,
> >
> > I am getting the following error with checkpatch.pl
> >
> > ERROR: externs should be avoided in .c files
> > #78: FILE: block/vxhs.c:28:
> > +QemuUUID qemu_u
From: Paolo Bonzini
All that CoQueue needs in order to become thread-safe is help
from an external mutex. Add this to the API.
Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
Message-id: 20170213181244.16297-6-pbonz...@redhat.com
Signed-off-by: Stefan Hajnoczi
---
include/qemu/coroutine
From: Halil Pasic
Wire up virtio-crypto for the CCW based VIRTIO.
Signed-off-by: Halil Pasic
Signed-off-by: Cornelia Huck
---
hw/s390x/virtio-ccw.c | 61 +++
hw/s390x/virtio-ccw.h | 12 ++
2 files changed, 73 insertions(+)
diff --git a/
According to
https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_platform_gbm.txt
if MESA_platform_gbm is supported display should be initialized
from a GBM handle using eglGetPlatformDisplayEXT.
Signed-off-by: Frediano Ziglio
---
This should fix
http://www.spinics.net/linux/fedora/libv
Can you still reproduce this issue with the latest version of QEMU?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1278166
Title:
Last commit to
From: Paolo Bonzini
This uses the lock-free mutex described in the paper '"Blocking without
Locking", or LFTHREADS: A lock-free thread library' by Gidenstam and
Papatriantafilou. The same technique is used in OSv, and in fact
the code is essentially a conversion to C of OSv's code.
[Added missi
From: Halil Pasic
Currently VIRTIO_CCW_QUEUE_MAX is defined as ADAPTER_ROUTES_MAX_GSI.
That is when checking queue max we implicitly check the constraint
concerning the number of adapter routes. This won't be satisfactory any
more (due to backward migration considerations) if ADAPTER_ROUTES_MAX_G
Current code puts a 'FLIC_FAILED' marker into the migration stream
to indicate something went wrong while saving flic state and fails
load if it encounters that marker. VMState's put routine recently
gained the ability to return error codes (but did not wire it up
yet).
In order to be able to reap
On Sun, Feb 19, 2017 at 02:30:53PM -0800, Ashish Mittal wrote:
> Source code for the qnio library that this code loads can be downloaded from:
> https://github.com/VeritasHyperScale/libqnio.git
>
> Sample command line using JSON syntax:
> ./x86_64-softmmu/qemu-system-x86_64 -name instance-0008
On Sat, Feb 18, 2017 at 12:30:31AM +, Ketan Nilangekar wrote:
> On 2/17/17, 1:42 PM, "Jeff Cody" wrote:
>
> On Thu, Feb 16, 2017 at 02:24:19PM -0800, ashish mittal wrote:
> > Hi,
> >
> > I am getting the following error with checkpatch.pl
> >
> > ERROR: externs shoul
A selection of s390x patches:
- cleanups and improvements
- program check loop detection (useful with the corresponding kernel
patch)
- wire up virtio-crypto for ccw
- and finally support many virtqueues for virtio-ccw
Christian Borntraeger (3):
s390x/kvm: detect some program check loops
s39
On 20 February 2017 at 06:21, Vijay Kilari wrote:
> Hi Peter,
>
> On Fri, Feb 17, 2017 at 7:25 PM, Peter Maydell
> wrote:
[on the guest-visible ICC_SRE_EL1 value]
>> Is there a situation where KVM might allow a value other
>> than 0x7?
>
> In KVM, the SRE_EL1 value is 0x1. During save, value
> r
From: Halil Pasic
To make virtio-ccw supports more that 64 virtqueues we will have to
increase ADAPTER_ROUTES_MAX_GSI which is currently limiting the number if
possible adapter routes. Of course increasing the number of supported
routes can break backwards migration.
Let us introduce a compatib
Signed-off-by: Nikunj A Dadhania
---
target/ppc/translate.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 2a2d071..77045be 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -1389
The DPRINTF approach is likely to introduce bitrot, and the preferred
way for debugging is tracing anyway. Fortunately, there are no users
(left), so nuke it.
Signed-off-by: Cornelia Huck
Reviewed-by: Halil Pasic
---
hw/s390x/s390-virtio.c | 10 --
1 file changed, 10 deletions(-)
diff
From: Christian Borntraeger
In binutils/libbfd (bfd/elf.c) it is enforced that all s390
specific ELF notes like e.g. NT_S390_PREFIX or NT_S390_CTRS
have "LINUX" specified as note name and that the namesz is
6. Otherwise the notes are ignored.
QEMU currently uses "CORE" for these notes. Up to now
From: Christian Borntraeger
Sometimes (e.g. early boot) a guest is broken in such ways that it loops
100% delivering operation exceptions (illegal operation) but the pgm new
PSW is not set properly. This will result in code being read from
address zero, which usually contains another illegal op.
From: Halil Pasic
As a preparation for wiring-up virtio-crypto, the first non-transitional
virtio device on the ccw transport, let us introduce a mechanism for
disabling revision 0. This is more or less equivalent with disabling
legacy as revision 0 is legacy only, and legacy drivers use the rev
POWER ISA 3.0 adds CA32 and OV32 status in 64-bit mode. Add the flags
and corresponding defines.
Moreover, CA32 is updated when CA is updated and OV32 is updated when OV
is updated.
Arithmetic instructions:
* Addition and Substractions:
addic, addic., subfic, addc, subfc, adde, subfe
From: Christian Borntraeger
we need to pass the cpuid into the pid field of the notes
section, otherwise the notes for different CPUs all have 0:
e.g. objdump -h shows:
old:
5 .reg-s390-prefix/0 0004
6 .reg-s390-prefix 0004 0
From: Halil Pasic
We cannot support more than 64 virtqueues with the 64 bits provided by
classic indicators. If a driver tries to setup classic indicators
(which it is free to do even for virtio-1 devices) for a device with
more than 64 virtqueues, we should reject the attempt so that the
driver
From: Halil Pasic
The maximal number of virtqueues per device can be limited on a per
transport basis. For virtio-ccw this limit is defined by
VIRTIO_CCW_QUEUE_MAX, however the limitation used to come form the
number of adapter routes supported by flic (via notifiers).
Recently the limitation of
* SO and OV reflects overflow of the 64-bit result in 64-bit mode and
overflow of the low-order 32-bit result in 32-bit mode
* OV32 reflects overflow of the low-order 32-bit independent of the mode
Signed-off-by: Nikunj A Dadhania
---
target/ppc/translate.c | 5 +++--
1 file changed, 3 insert
17.02.2017 17:24, Kevin Wolf wrote:
Am 17.02.2017 um 14:48 hat Denis V. Lunev geschrieben:
On 02/17/2017 04:34 PM, Kevin Wolf wrote:
Am 17.02.2017 um 14:22 hat Denis V. Lunev geschrieben:
But for sure this is bad from the downtime point of view.
On migrate you will have to write to the image a
From: Halil Pasic
Let's increase ADAPTER_ROUTES_MAX_GSI to VIRTIO_QUEUE_MAX which is the
largest demand foreseeable at the moment. Let us add a compatibility
macro for the previous machines so client code can maintain backwards
migration compatibility
To not mess up migration compatibility for v
This series contains implentation of CA32 and OV32 bits added to the
ISA 3.0. Various fixed-point arithmetic instructions are updated to take
care of the newer flags.
Finally the last patch adds new instruction mcrxrx, that helps reading
the carry (CA and CA32) and the overflow (OV and OV32) fl
Signed-off-by: Nikunj A Dadhania
---
target/ppc/translate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 5d8d109..9fa3b5a 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -1483,7 +1483,7 @@ static inli
17.02.2017 18:48, Eric Blake wrote:
On 02/17/2017 04:18 AM, Vladimir Sementsov-Ogievskiy wrote:
16.02.2017 17:21, Kevin Wolf wrote:
Am 15.02.2017 um 11:10 hat Vladimir Sementsov-Ogievskiy geschrieben:
Add detailed error messages.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Why not merge thi
For Multiply Word:
SO, OV, and OV32 bits reflects overflow of the 32-bit result
For Multiply DoubleWord:
SO, OV, and OV32 bits reflects overflow of the 64-bit result
Signed-off-by: Nikunj A Dadhania
---
target/ppc/translate.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/ppc/tran
* Laszlo Ersek (ler...@redhat.com) wrote:
> CC Dave
This isn't an area I really understand; but if I'm
reading this right then
vmgenid is stored in fw_cfg?
fw_cfg isn't migrated
So why should any changes to it get migrated, except if it's already
been read by the guest (and if the guest re
mcrxrx: Move to CR from XER Extended
Signed-off-by: Nikunj A Dadhania
---
target/ppc/translate.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index ee44205..36d59a5 100644
--- a/target/ppc/translate.c
+++ b/target/pp
On 13.02.2017 18:22, Kevin Wolf wrote:
> We want every user to be specific about the permissions it needs, so
> we'll pass the initial permissions as parameters to blk_new(). A user
> only needs to call blk_set_perm() if it wants to change the permissions
> after the fact.
>
> The permissions are
On 02/20/17 11:23, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
>> CC Dave
>
> This isn't an area I really understand; but if I'm
> reading this right then
>vmgenid is stored in fw_cfg?
>fw_cfg isn't migrated
>
> So why should any changes to it get migrated,
Adds routine to compute ca32 - gen_op_arith_compute_ca32
For 64-bit mode use the compute ca32 routine. While for 32-bit mode, CA
and CA32 will have same value.
Signed-off-by: Nikunj A Dadhania
---
target/ppc/translate.c | 32
1 file changed, 32 insertions(+)
di
For 64-bit mode use the compute ca32 routine. While for 32-bit mode, CA
and CA32 will have same value.
Signed-off-by: Nikunj A Dadhania
---
target/ppc/translate.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 77045be..dd413de 100644
-
For 64-bit mode if the register RA contains 0x8000___, OV
and OV32 are set to 1.
For 32-bit mode if the register RA contains 0x8000_, OV and OV32 are
set to 1.
Use the tcg-ops for negation (neg_tl) and drop gen_op_arith_neg() as
nego was the last user.
Signed-off-by: Nikunj A Dad
Add helper_div_compute_ov() in the int_helper for updating the overflow
flags.
For Divide Word:
SO, OV, and OV32 bits reflects overflow of the 32-bit result
For Divide DoubleWord:
SO, OV, and OV32 bits reflects overflow of the 64-bit result
Signed-off-by: Nikunj A Dadhania
---
target/ppc/int_h
The docker framework is really just another piece in the build
automation puzzle so lets merge it together. For added bonus I've also
included the Travis and Patchew status links. The Shippable links will
be added later once mainline tests have been configured and setup.
Signed-off-by: Alex Bennée
Ostensibly Shippable offers a similar set of services as Travis.
However they are focused on Docker container based work-flows so we
can use our existing containers to run a few extra builds - in this
case a bunch of cross-compiled targets on a Debian multiarch system.
Signed-off-by: Alex Bennée
Hi Fam,
Hopefully this is the final iteration. A couple of minor typos fixes
and your suggestions taken into account. I have also added some
review/tesing tags from Philippe.
Alex.
Alex Bennée (4):
tests/docker: add basic user mapping support
new: debian docker targets for cross-compiling
Currently all docker builds are done by exporting a tarball to the
docker container and running the build as the containers root user.
Other use cases are possible however and it is possible to map a part
of users file-system to the container. This is useful for example for
doing cross-builds of ar
This provides a basic Debian install with access to the emdebian cross
compilers. The debian-armhf-cross and debian-arm64-cross targets build
on the basic Debian image to allow cross compiling to those targets.
A new environment variable (QEMU_CONFIGURE_OPTS) is set as part of the
docker container
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 02/20/17 11:23, Dr. David Alan Gilbert wrote:
> > * Laszlo Ersek (ler...@redhat.com) wrote:
> >> CC Dave
> >
> > This isn't an area I really understand; but if I'm
> > reading this right then
> >vmgenid is stored in fw_cfg?
> >fw_cfg isn't mi
On Sat, Feb 18, 2017 at 12:30:31AM +, Ketan Nilangekar wrote:
> On 2/17/17, 1:42 PM, "Jeff Cody" wrote:
>
> On Thu, Feb 16, 2017 at 02:24:19PM -0800, ashish mittal wrote:
> > Hi,
> >
> > I am getting the following error with checkpatch.pl
> >
> > ERROR: externs shoul
On 13.02.2017 18:22, Kevin Wolf wrote:
> Mow that blk_insert_bs() requests the BlockBackend permissions for the
> node it attaches to, it can fail. Instead of aborting, pass the errors
> to the callers.
So it does qualify as a FIXME, but just for a single patch. Good. :-)
> Signed-off-by: Kevin W
On 20/02/2017 10:19, Gonglei (Arei) wrote:
> Hi Paolo,
>
>>
>>
>> On 16/02/2017 02:31, Gonglei (Arei) wrote:
>>> And the below patch works for me, I can support max 255 vcpus for WS2012
>>> with hyper-v enlightenments.
>>>
>>> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
>>> index 27fd050.
On Wed, Feb 15, 2017 at 05:49:58PM +0200, Nir Soffer wrote:
> On Wed, Feb 15, 2017 at 5:14 PM, Stefan Hajnoczi wrote:
> > On Mon, Feb 13, 2017 at 05:46:19PM +0200, Maor Lipchuk wrote:
> >> I was wondering if that is possible to provide a new API that
> >> estimates the size of
> >> qcow2 image con
On Wed, Feb 15, 2017 at 04:07:43PM +, Daniel P. Berrange wrote:
> On Wed, Feb 15, 2017 at 05:57:12PM +0200, Nir Soffer wrote:
> > On Wed, Feb 15, 2017 at 5:20 PM, Daniel P. Berrange
> > wrote:
> > > On Wed, Feb 15, 2017 at 03:14:19PM +, Stefan Hajnoczi wrote:
> > >> On Mon, Feb 13, 2017 a
Am 18.02.2017 um 11:54 hat Denis V. Lunev geschrieben:
> On 02/17/2017 03:54 PM, Vladimir Sementsov-Ogievskiy wrote:
> > 17.02.2017 17:24, Kevin Wolf wrote:
> >> Am 17.02.2017 um 14:48 hat Denis V. Lunev geschrieben:
> >>> On 02/17/2017 04:34 PM, Kevin Wolf wrote:
> Am 17.02.2017 um 14:22 hat
On 13.02.2017 18:22, Kevin Wolf wrote:
> We can figure out the necessary permissions from the flags that the
> caller passed.
>
> Signed-off-by: Kevin Wolf
> ---
> block/block-backend.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/block/block-backen
Am 20.02.2017 um 12:04 hat Max Reitz geschrieben:
> On 13.02.2017 18:22, Kevin Wolf wrote:
> > Mow that blk_insert_bs() requests the BlockBackend permissions for the
> > node it attaches to, it can fail. Instead of aborting, pass the errors
> > to the callers.
>
> So it does qualify as a FIXME, bu
From: Prasad J Pandit
Crypto routines 'qcrypto_cipher_get_block_len' and
'qcrypto_cipher_get_key_len' return non-zero cipher block and key
lengths from static arrays 'alg_block_len[]' and 'alg_key_len[]'
respectively. Returning 'zero(0)' value from either of them would
likely lead to an error con
On 20.02.2017 12:22, Kevin Wolf wrote:
> Am 20.02.2017 um 12:04 hat Max Reitz geschrieben:
>> On 13.02.2017 18:22, Kevin Wolf wrote:
>>> Mow that blk_insert_bs() requests the BlockBackend permissions for the
>>> node it attaches to, it can fail. Instead of aborting, pass the errors
>>> to the calle
On 13.02.2017 18:22, Kevin Wolf wrote:
> Some devices allow a media change between read-only and read-write
> media. They need to adapt the permissions in their .change_media_cb()
> implementation, which can fail. So add an Error parameter to the
> function.
>
> Signed-off-by: Kevin Wolf
> ---
>
On Thu, Feb 16, 2017 at 12:07:02PM -0500, Jeff Cody wrote:
> On Thu, Feb 16, 2017 at 10:47:07AM -0500, Jeff Cody wrote:
> > On Thu, Feb 16, 2017 at 03:30:25PM +, Stefan Hajnoczi wrote:
> > > Hi Jeff,
> > > The old qemu.org/images/ links are not being rewritten to
> > > wiki.qemu-project.org/ima
On Mon, Feb 20, 2017 at 3:02 AM, Stefan Hajnoczi wrote:
> On Sat, Feb 18, 2017 at 12:30:31AM +, Ketan Nilangekar wrote:
>> On 2/17/17, 1:42 PM, "Jeff Cody" wrote:
>>
>> On Thu, Feb 16, 2017 at 02:24:19PM -0800, ashish mittal wrote:
>> > Hi,
>> >
>> > I am getting the following
On 02/20/17 12:00, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
>> On 02/20/17 11:23, Dr. David Alan Gilbert wrote:
>>> * Laszlo Ersek (ler...@redhat.com) wrote:
CC Dave
>>>
>>> This isn't an area I really understand; but if I'm
>>> reading this right then
>>>
On Mon, Feb 20, 2017 at 04:53:07PM +0530, P J P wrote:
> From: Prasad J Pandit
>
> Crypto routines 'qcrypto_cipher_get_block_len' and
> 'qcrypto_cipher_get_key_len' return non-zero cipher block and key
> lengths from static arrays 'alg_block_len[]' and 'alg_key_len[]'
> respectively. Returning 'z
1 - 100 of 400 matches
Mail list logo
