Hi Daniel,
On 07/18/2018 06:38 AM, Daniel P. Berrangé wrote:
> The test-vmstate test is a bit chatty because it triggers various
> expected failure scenarios and the code in question uses error_report
> instead of accepting 'Error **errp' parameters. To silence this test the
> stubs for
On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote:
iiuc, this possibly implies AIO was not actually used previously on this
guest (it might have silently been falling back to threaded IO?). I
don't have access to s390x, but would it be possible to run qemu under
gdb and see if
Hi Daniel,
On 07/18/2018 06:38 AM, Daniel P. Berrangé wrote:
> Calling qcrypto_init ensures that all relevant initialization is
> done. In particular this honours the debugging settings and thread
> settings.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> tests/crypto-tls-x509-helpers.c | 4
On 07/17/2018 04:40 PM, Eduardo Habkost wrote:
> Rename DCACHE to DATA_CACHE and ICACHE to INSTRUCTION_CACHE.
>
> This avoids conflict with Linux asm/cachectl.h macros and fixes
> build failure on mips hosts.
>
> Reported-by: Philippe Mathieu-Daudé
> Signed-off-by: Eduardo Habkost
Acked-by:
On 07/17/2018 04:26 PM, Peter Maydell wrote:
> On 14 July 2018 at 18:15, Luc Michel wrote:
>> Add the read/write functions to handle accesses to the vCPU interface.
>> Those accesses are forwarded to the real CPU interface, with the CPU id
>> being converted to the corresponding vCPU id (vCPU id
On 07/17/2018 03:32 PM, Peter Maydell wrote:
> On 14 July 2018 at 18:15, Luc Michel wrote:
>> Implement virtualization extensions in the gic_deactivate_irq() and
>> gic_complete_irq() functions. When a guest tries to deactivat or end an
>
> "deactivate"
>
>> IRQ that does not exist in the
Peter Xu writes:
> On Tue, Jul 17, 2018 at 08:08:55PM +0800, Peter Xu wrote:
>
> [...]
>
>> >
>> > Whatever we don't address right away we should at least mark FIXME in
>> > the source code.
>> >
>> > Assuming my list is complete, and my assessments correct, then we're
>> > quite close to the
On Tue, 3 Jul 2018 09:19:49 +0200
Eric Auger wrote:
> We define a new hotpluggable RAM region (aka. device memory).
> Its base is 2TB GPA. This obviously requires 42b IPA support
> in KVM/ARM, FW and guest kernel. At the moment the device
> memory region is max 2TB.
>
> This is largely
On Thu, 12 Jul 2018 16:53:01 +0200
Auger Eric wrote:
> Hi Drew,
>
> On 07/12/2018 04:45 PM, Andrew Jones wrote:
> > On Thu, Jul 12, 2018 at 04:22:05PM +0200, Auger Eric wrote:
> >> Hi Igor,
> >>
> >> On 07/11/2018 03:17 PM, Igor Mammedov wrote:
> >>> On Thu, 5 Jul 2018 16:27:05 +0200
> >>>
Public bug reported:
I test COLO feature on my host following docs/COLO-FT.txt in qemu folder, but
fail to failover to secondary VM.
Is there any mistake in my execution steps?
Execution environment:
QEMU v2.12.0-rc4
OS: Ubuntu 16.04.3 LTS
Kernel: Linux 4.4.35
Secondary VM IP: noted as
On Fri, 13 Jul 2018 13:22:32 +0530
Pankaj Gupta wrote:
> This patch adds virtio-pmem Qemu device.
>
> This device presents memory address range information to guest
> which is backed by file backend type. It acts like persistent
> memory device for KVM guest. Guest can perform read and
On Wed, Jul 18, 2018 at 12:22:02PM +1000, David Gibson wrote:
> On Mon, Jul 16, 2018 at 07:03:12PM +, Yasmin Beatriz wrote:
> > When the result of bcdsub is equal to zero, the result sign may be
> > set to negative in some cases, and this does not follow the Power ISA
> > specifications as to
On Wed, 18 Jul 2018 11:23:30 +0200
David Hildenbrand wrote:
> Usually, when baselining two CPU models, whereby one of them has base
> CPU features disabled (e.g. z14-base,msa=off), we fallback to an older
> model that did not have these features in the base model. We always try to
> create a
libgcrypt 1.5.0 was released in 2011 and all the distros that are build
target platforms for QEMU [1] include it:
RHEL-7: 1.5.3
Debian (Stretch): 1.7.6
Debian (Jessie): 1.6.3
OpenBSD (ports): 1.8.2
FreeBSD (ports): 1.8.3
OpenSUSE Leap 15: 1.8.2
Ubuntu (Xenial): 1.6.5
macOS
nettle 2.7.1 was released in 2013 and all the distros that are build
target platforms for QEMU [1] include it:
RHEL-7: 2.7.1
Debian (Stretch): 3.3
Debian (Jessie): 2.7.1
OpenBSD (ports): 3.4
FreeBSD (ports): 3.4
OpenSUSE Leap 15: 3.4
Ubuntu (Xenial): 3.2
macOS (Homebrew): 3.4
gnutls 3.0.0 was released in 2011 and all the distros that are build
target platforms for QEMU [1] include it:
RHEL-7: 3.1.18
Debian (Stretch): 3.5.8
Debian (Jessie): 3.3.8
OpenBSD (ports): 3.5.18
FreeBSD (ports): 3.5.18
OpenSUSE Leap 15: 3.6.2
Ubuntu (Xenial): 3.4.10
macOS
Since adopting a formal policy around supported build hosts, and
increasing the minimum required glib version, it is now possible to also
increase the min required versions for gnutls, gcrypt and nettle
libraries. This allows simplification of a bunch of conditional logic.
Daniel P. Berrangé (3):
Hello Dominique, or anyone else affected,
Accepted qemu into xenial-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-
5ubuntu10.31 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
On 07/18/2018 01:35 PM, Cornelia Huck wrote:
So to translate the new stuff we would actually have to stop the channel
program and resubmit the rest (either by suspend+resume or by break
chaining+ssch). The problem with that an execution of a channel program
that is composed of four ccws
On 07/05/2018 07:25 PM, Jason J. Herne wrote:
From: "Jason J. Herne"
Allows guest to boot from a vfio configured real dasd device.
Signed-off-by: Jason J. Herne
Signed-off-by: Jason J. Herne
---
docs/devel/s390-dasd-ipl.txt | 132 +++
pc-bios/s390-ccw/Makefile|
On Wed, 18 Jul 2018 12:55:51 +0200
Halil Pasic wrote:
> On 07/18/2018 09:40 AM, Cornelia Huck wrote:
> > On Tue, 17 Jul 2018 22:43:27 +0200
> > David Hildenbrand wrote:
> >
> >> On 05.07.2018 19:25, Jason J. Herne wrote:
> >
> >>> +*
> >>> +*
On 07/18/2018 11:23 AM, David Hildenbrand wrote:
> Usually, when baselining two CPU models, whereby one of them has base
> CPU features disabled (e.g. z14-base,msa=off), we fallback to an older
> model that did not have these features in the base model. We always try to
> create a "sane" CPU
On 07/18/2018 09:40 AM, Cornelia Huck wrote:
On Tue, 17 Jul 2018 22:43:27 +0200
David Hildenbrand wrote:
On 05.07.2018 19:25, Jason J. Herne wrote:
+*
+* How this all pertains to Qemu *
+*
+
+In
Add initial tests which check basic computations and error cases on the
PFPU.
Signed-off-by: Michael Walle
---
MAINTAINERS | 1 +
hw/lm32/lm32.h | 2 +
tests/Makefile.include | 4 +
tests/milkymist-pfpu-test.c | 193
It is only possible to retrieve the current state of an interrupt line. But
there are devices which just pulses the interrupt line. Introduce a latch
which is set by qtest and which can be cleared by the test case.
Signed-off-by: Michael Walle
Cc: Paolo Bonzini
Cc: Andreas Färber
---
Emulate write collisions, stray writes and microcode which has no VECTOUT
opcode. Although the latter was supported before, the emulation was
incorrect.
Signed-off-by: Michael Walle
---
hw/misc/milkymist-pfpu.c | 105 +--
1 file changed, 75
On Wed, Jul 18, 2018 at 10:50:34AM +0100, Daniel P. Berrangé wrote:
> On Wed, Jul 18, 2018 at 12:41:48PM +0300, Hetz Ben Hamo wrote:
> > Hi,
> >
> > I've been looking at the CPU list and although I see lots of CPU's, I
> > cannot find 2 CPU families:
> >
> > * AMD Ryzen
> > * AMD Threadripper
>
On Wed, Jul 18, 2018 at 04:56:13PM +0800, Xiao Guangrong wrote:
>
>
> On 07/12/2018 04:26 PM, Peter Xu wrote:
> > On Thu, Jul 12, 2018 at 03:47:57PM +0800, Xiao Guangrong wrote:
> > >
> > >
> > > On 07/11/2018 04:21 PM, Peter Xu wrote:
> > > > On Thu, Jun 28, 2018 at 05:33:58PM +0800, Xiao
Am 2018-07-02 03:40, schrieb Philippe Mathieu-Daudé:
qemu_log_mask(GUEST_ERROR) is more appropriate:
$ qemu -d help
Log items (comma separated):
guest_errorslog when the guest OS does something invalid (eg
accessing a non-existent register)
Signed-off-by: Philippe Mathieu-Daudé
I may have found the issue and if it is the case it should be fixed after
applying: http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg00820.html
Is there a reason why this patch is not backported to 2.11.2?
The theory is that the VM is not actually "frozen", but catching up in time, as
- travis - doesn't support non-x8
- centos7 - only AltArch, next release should have support
- debian-8 based - docker hub issue?
- ubuntu - image a bit old, maybe update to 18.04
Signed-off-by: Alex Bennée
---
tests/docker/Makefile.include | 7 +++
1 file changed, 7 insertions(+)
diff
When we can't use the debian-mips64el-cross to build our tests we can
use the user-cross fallback.
Signed-off-by: Alex Bennée
---
tests/tcg/mips/Makefile.include | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/tcg/mips/Makefile.include b/tests/tcg/mips/Makefile.include
index
We have a mechansim (DOCKER_PARTIAL_IMAGES) for marking stuff that is
incomplete or won't build. We can use this to avoid attempting to
build them at the top of a check-tcg build. We need to move the
inclusion of docker/Makefile.include to ensure everything is resolved
by this point.
We also have
Attempting to install the native compiler as a cross compiler rarely
goes well.
Signed-off-by: Alex Bennée
---
tests/docker/Makefile.include | 4
1 file changed, 4 insertions(+)
diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 7d13ddd497..2cb180ff6c 100644
When building on non-x86 systems the base system will be correct so if
we avoid too many x86'isms in the install we can still use the image.
Signed-off-by: Alex Bennée
---
.../dockerfiles/{debian-amd64.docker => debian-host.docker} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
The Debian archives don't package their large array of cross compilers
for all host architectures. For MIPS let's fall back to a linux-user
based image when we can't use the native ones.
Signed-off-by: Alex Bennée
---
tests/docker/Makefile.include| 11 +++
The Debian archives don't package their large array of cross compilers
for all host architectures. For ppc64el let's fall back to a linux-user
based image when we can't use the native ones.
Signed-off-by: Alex Bennée
---
tests/docker/Makefile.include| 10 +-
We want to keep all our variations in one place. This is that place.
Signed-off-by: Alex Bennée
---
tests/docker/Makefile.include | 12
1 file changed, 12 insertions(+)
diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 22adf6ac73..7d13ddd497 100644
The Debian archives don't package their large array of cross compilers
for all host architectures. For s390x let's fall back to a linux-user
based image when we can't use the native ones.
Signed-off-by: Alex Bennée
---
tests/docker/Makefile.include| 9 -
We also evaluate this list later in the build rule after all decisions
about what will and won't be built have been made.
Signed-off-by: Alex Bennée
---
tests/docker/Makefile.include | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/tests/docker/Makefile.include
Hi,
Our existing support for docker is fairly x86 centric. While docker
itself has support for multiple architectures not all architectures
are equal. For example Debian only packages the widest range of
cross-compilers in it's x86 images (although for example armhf is
available on aarch64 based
Forbid stack alignment change. (CCR)
Reserve FAULTMASK, BASEPRI registers.
Report any fault as a HardFault. Disable MemManage, BusFault and
UsageFault, so they always escalated to HardFault. (SHCSR)
Signed-off-by: Julia Suvorova
---
v2:
* Changed CCR reset value
hw/intc/armv7m_nvic.c | 10
On Wed, Jul 18, 2018 at 12:41:48PM +0300, Hetz Ben Hamo wrote:
> Hi,
>
> I've been looking at the CPU list and although I see lots of CPU's, I
> cannot find 2 CPU families:
>
> * AMD Ryzen
> * AMD Threadripper
>
> Although EPYC has been added recently.
>
> Are there any missing details which
When gnutls negotiates TLS 1.3 instead of 1.2, the order of messages
sent by the handshake changes. This exposed a logic bug in the test
suite which caused us to wait for the server to see handshake
completion, but not wait for the client to see completion. The result
was the client didn't receive
Most of the TLS related tests are passing an in a "Error" object to
methods that are expected to fail, but then ignoring any error that is
set and instead asserting on a return value. This means that when an
error is unexpectedly raised, no information about it is printed out,
making failures hard
The switch to enable TLS 1.3 protocol support in GNUTLS in Fedora
exposed a subtle flaw in our TLS unit tests. This was horrible to debug
because of bad error reporting in our tests which caused all the error
messages to be irretrievably lost instead of displayed on stderr.
Daniel P. Berrangé
Calling qcrypto_init ensures that all relevant initialization is
done. In particular this honours the debugging settings and thread
settings.
Signed-off-by: Daniel P. Berrangé
---
tests/crypto-tls-x509-helpers.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
The test-vmstate test is a bit chatty because it triggers various
expected failure scenarios and the code in question uses error_report
instead of accepting 'Error **errp' parameters. To silence this test the
stubs for error_vprintf() were changed to send errors via
g_test_message() instead of
On Wed, 18 Jul 2018 14:48:03 +0800
Peter Xu wrote:
> On Tue, Jul 17, 2018 at 04:47:31PM -0600, Alex Williamson wrote:
> > Directly assigned vfio devices have never been compatible with
> > ballooning. Zapping MADV_DONTNEED pages happens completely
> > independent of vfio page pinning and IOMMU
Usually, when baselining two CPU models, whereby one of them has base
CPU features disabled (e.g. z14-base,msa=off), we fallback to an older
model that did not have these features in the base model. We always try to
create a "sane" CPU model (as far as possible), and one part of it is that
On Wed, Jul 18, 2018 at 11:05:57AM +0200, Markus Armbruster wrote:
> Making 'allow-oob' optional in SchemaInfoCommand permits omitting it
> in the common case. Shrinks query-qmp-schema's output from 122.1KiB
> to 118.6KiB for me.
>
> Note that out-of-band execution is still experimental (you
On Wed, 18 Jul 2018 10:50:01 +0200
David Hildenbrand wrote:
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index cfdbccf46d..604898a882 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -716,6 +716,14 @@ CpuModelBaselineInfo
>
Making 'allow-oob' optional in SchemaInfoCommand permits omitting it
in the common case. Shrinks query-qmp-schema's output from 122.1KiB
to 118.6KiB for me.
Note that out-of-band execution is still experimental (you have to
configure the monitor with x-oob=on to use it).
Signed-off-by: Markus
On 07/12/2018 04:26 PM, Peter Xu wrote:
On Thu, Jul 12, 2018 at 03:47:57PM +0800, Xiao Guangrong wrote:
On 07/11/2018 04:21 PM, Peter Xu wrote:
On Thu, Jun 28, 2018 at 05:33:58PM +0800, Xiao Guangrong wrote:
On 06/19/2018 03:36 PM, Peter Xu wrote:
On Mon, Jun 04, 2018 at 05:55:15PM
On 07/17/2018 03:01 AM, Dr. David Alan Gilbert wrote:
* Xiao Guangrong (guangrong.x...@gmail.com) wrote:
On 06/14/2018 12:25 AM, Dr. David Alan Gilbert wrote:
}
static void migration_bitmap_sync(RAMState *rs)
@@ -1412,6 +1441,9 @@ static void flush_compressed_data(RAMState *rs)
On 18.07.2018 10:44, Christian Borntraeger wrote:
>
>
> On 07/18/2018 10:40 AM, David Hildenbrand wrote:
>> On 18.07.2018 10:39, Christian Borntraeger wrote:
>>>
>>>
>>> On 07/18/2018 10:24 AM, David Hildenbrand wrote:
Usually, when baselining two CPU models, whereby one of them has base
On Tue, Jul 17, 2018 at 08:08:55PM +0800, Peter Xu wrote:
[...]
> >
> > Whatever we don't address right away we should at least mark FIXME in
> > the source code.
> >
> > Assuming my list is complete, and my assessments correct, then we're
> > quite close to the point where we can enable OOB.
On 07/17/2018 02:58 AM, Dr. David Alan Gilbert wrote:
* Xiao Guangrong (guangrong.x...@gmail.com) wrote:
On 06/29/2018 05:42 PM, Dr. David Alan Gilbert wrote:
* Xiao Guangrong (guangrong.x...@gmail.com) wrote:
Hi Peter,
Sorry for the delay as i was busy on other things.
On 06/19/2018
On Wed, 18 Jul 2018 10:40:18 +0200
David Hildenbrand wrote:
> On 18.07.2018 10:39, Christian Borntraeger wrote:
> >
> >
> > On 07/18/2018 10:24 AM, David Hildenbrand wrote:
> >> Usually, when baselining two CPU models, whereby one of them has base
> >> CPU features disabled (e.g.
On 07/18/2018 10:40 AM, David Hildenbrand wrote:
> On 18.07.2018 10:39, Christian Borntraeger wrote:
>>
>>
>> On 07/18/2018 10:24 AM, David Hildenbrand wrote:
>>> Usually, when baselining two CPU models, whereby one of them has base
>>> CPU features disabled (e.g. z14-base,msa=off), we fallback
On 07/14/2018 02:01 AM, Dr. David Alan Gilbert wrote:
* guangrong.x...@gmail.com (guangrong.x...@gmail.com) wrote:
From: Xiao Guangrong
flush_compressed_data() needs to wait all compression threads to
finish their work, after that all threads are free until the
migration feed new request
If we know we've already locked the bytes, don't do it again; similarly
don't unlock a byte if we haven't locked it. This doesn't change the
behavior, but fixes a corner case explained below.
Libvirt had an error handling bug that an image can get its (ownership,
file mode, SELinux) permissions
On 18.07.2018 10:39, Christian Borntraeger wrote:
>
>
> On 07/18/2018 10:24 AM, David Hildenbrand wrote:
>> Usually, when baselining two CPU models, whereby one of them has base
>> CPU features disabled (e.g. z14-base,msa=off), we fallback to an older
>> model that did not have these features in
On 07/18/2018 10:24 AM, David Hildenbrand wrote:
> Usually, when baselining two CPU models, whereby one of them has base
> CPU features disabled (e.g. z14-base,msa=off), we fallback to an older
> model that did not have these features in the base model. We always try to
> create a "sane" CPU
Usually, when baselining two CPU models, whereby one of them has base
CPU features disabled (e.g. z14-base,msa=off), we fallback to an older
model that did not have these features in the base model. We always try to
create a "sane" CPU model (as far as possible), and one part of it is that
On Mon, Jul 02, 2018 at 04:18:43PM +0100, Stefan Hajnoczi wrote:
> On Fri, Jun 29, 2018 at 03:40:50PM +0300, Denis Plotnikov wrote:
> > There are cases when a request to a block driver state shouldn't have
> > appeared producing dangerous race conditions.
> > This misbehaviour is usually happens
On Mon, 16 Jul 2018 16:46:59 +0200
Igor Mammedov wrote:
> On Mon, 16 Jul 2018 14:59:46 +0200
> Marc-André Lureau wrote:
>
> > From: Stefan Berger
> >
> > To avoid having to hard code the base address of the PPI virtual
> > memory device we introduce a fw_cfg file etc/tpm/config that holds
Qemu initialize the MigrationIncomingState structure in migration_object_init,
but not release it. this patch release it in migration_object_finalize.
Signed-off-by: Lidong Chen
---
migration/migration.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/migration/migration.c
On Wed, 2018-07-18 at 16:12 +1000, David Gibson wrote:
> On Thu, Jun 28, 2018 at 10:36:32AM +0200, Cédric Le Goater wrote:
> > From: Benjamin Herrenschmidt
Can you trim your replies ? It's really hard to find your comments in
such a long patch...
> > diff --git a/include/hw/ppc/xics.h
From: Junyan He
Because we need to make sure the pmem kind memory data is synced
after migration, we choose to call pmem_persist() when the migration
finish. This will make sure the data of pmem is safe and will not
lose if power is off.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
From: Junyan He
The nvdimm kind memory does not support post copy now.
We disable post copy if we have nvdimm memory and print some
log hint to user.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Igor Mammedov
---
migration/ram.c | 9 +
1 file changed, 9
On 16.07.2018 21:59, John Snow wrote:
On 07/16/2018 11:01 AM, Denis Plotnikov wrote:
Ping!
I never saw a reply to Stefan's question on July 2nd, did you reply
off-list?
For some reason, there are no Stefan's replies on my server. Found it in
the web. Will respond to it shortly.
From: Junyan He
Guest writes to vNVDIMM labels are intercepted and performed on the
backend by QEMU. When the backend is a real persistent memort, QEMU
needs to take proper operations to ensure its write persistence on the
persistent memory. Otherwise, a host power failure may result in the
loss
On 18.07.2018 09:40, Cornelia Huck wrote:
> On Tue, 17 Jul 2018 22:43:27 +0200
> David Hildenbrand wrote:
>
>> On 05.07.2018 19:25, Jason J. Herne wrote:
>
>>> +*
>>> +* How this all pertains to Qemu *
>>>
From: Junyan He
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it
needs to know whether the backend storage is a real persistent memory,
in order to decide whether special operations should be performed to
ensure the data persistence.
This boolean option 'pmem' allows users to
From: Junyan He
We need to use these flags in other files rather than just in exec.c,
For example, RAM_SHARED should be used when create a ram block from file.
We expose them the exec/memory.h
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Igor Mammedov
Reviewed-by:
From: Junyan He
As more flag parameters besides the existing 'share' are going to be
added to following functions
memory_region_init_ram_from_file
qemu_ram_alloc_from_fd
qemu_ram_alloc_from_file
let's switch them to use the 'flags' parameters so as to ease future
flag additions.
The existing
From: Junyan He
Add a pair of configure options --{enable,disable}-libpmem to control
whether QEMU is compiled with PMDK libpmem [1].
QEMU may write to the host persistent memory (e.g. in vNVDIMM label
emulation and live migration), so it must take the proper operations
to ensure the
From: Junyan He
QEMU writes to vNVDIMM backends in the vNVDIMM label emulation and live
migration.
If the backend is on the persistent memory, QEMU needs to take proper
operations to
ensure its writes persistent on the persistent memory. Otherwise, a host power
failure
may result in the loss
On Tue, 17 Jul 2018 22:43:27 +0200
David Hildenbrand wrote:
> On 05.07.2018 19:25, Jason J. Herne wrote:
> > +*
> > +* How this all pertains to Qemu *
> > +*
> > +
> > +In theory we should merely have to do
On Tue, Jul 17, 2018 at 08:40:15PM -0300, Philippe Mathieu-Daudé wrote:
> Since 356dc290f the Fedora image default to Python3.
>
> This fixes:
>
> $ make docker-test-block@fedora
> [...]
> 045 [failed, exit status 1] - output mismatch (see 045.out.bad)
> ---
On Tue, Jul 17, 2018 at 08:37:58PM -0300, Philippe Mathieu-Daudé wrote:
> I noticed this while running "make docker-test-block@fedora":
>
> $ make docker-test-block@fedora NETWORK=1
> BUILD fedora
> RUN test-block in qemu:fedora
> Configure options:
> --enable-werror
On 17.07.2018 22:27, Alistair Francis wrote:
> This is based on Thomas's work fixing introspection problems [1] and
> applied to the RISC-V port.
>
> 1: https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg03261.html
>
> Alistair Francis (5):
> sifive_e: Fix crash when introspecting the
On 17.07.2018 22:27, Alistair Francis wrote:
> This is based on Thomas's work fixing introspection problems [1] and
> applied to the RISC-V port.
>
> 1: https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg03261.html
>
> Alistair Francis (5):
> sifive_e: Fix crash when introspecting the
On 07/14/2018 12:24 AM, Dr. David Alan Gilbert wrote:
+static void *thread_run(void *opaque)
+{
+ThreadLocal *self_data = (ThreadLocal *)opaque;
+Threads *threads = self_data->threads;
+void (*handler)(ThreadRequest *data) = threads->thread_request_handler;
+ThreadRequest
Hi Stefan,
> > + /* The request submission function */
> > +static int virtio_pmem_flush(struct device *dev)
> > +{
> > + int err;
> > + unsigned long flags;
> > + struct scatterlist *sgs[2], sg, ret;
> > + struct virtio_device *vdev = dev_to_virtio(dev->parent->parent);
> > + struct
On Tue, Jul 17, 2018 at 04:47:31PM -0600, Alex Williamson wrote:
> Directly assigned vfio devices have never been compatible with
> ballooning. Zapping MADV_DONTNEED pages happens completely
> independent of vfio page pinning and IOMMU mapping, leaving us with
> inconsistent GPA to HPA mapping
On Tue, Jul 17, 2018 at 04:47:37PM -0600, Alex Williamson wrote:
> A simple true/false internal state does not allow multiple users. Fix
> this within the existing interface by converting to a counter, so long
> as the counter is elevated, ballooning is inhibited.
>
> Signed-off-by: Alex
Hi all,
I have two issues when cross compiling current master for Windows with
mingw 8.1. Host is Fedora29. See further below for gcc and mingw
versions.
Reproduce with:
./configure --cross-prefix=x86_64-w64-mingw32-
--target-list="ppc-softmmu" --enable-gtk --with-gtkabi=3.0
--enable-sdl
On Thu, Jun 28, 2018 at 10:36:32AM +0200, Cédric Le Goater wrote:
> From: Benjamin Herrenschmidt
>
> This is a model of the PCIe Host Bridge (PHB3) found on a Power8
> processor. It includes the PowerBus logic interface (PBCQ), IOMMU
> support, PCIe root complex, the XICS MSI and LSI interrupt
On Mon, Jul 09, 2018 at 09:22:59AM +0200, Cédric Le Goater wrote:
> On 06/28/2018 10:36 AM, Cédric Le Goater wrote:
> > From: Benjamin Herrenschmidt
> >
> > This is a model of the PCIe Host Bridge (PHB3) found on a Power8
> > processor. It includes the PowerBus logic interface (PBCQ), IOMMU
> >
Those comments change often when ui/gtk.c is changed and are not
really useful.
Add also a new translation for German (still to be done for all other
languages).
Signed-off-by: Stefan Weil
---
CC'ing all translators because of the new string which still needs
translations.
Regards
Stefan
101 - 192 of 192 matches
Mail list logo
