Currently when the splash-time value is bigger than 0x
we report and correct it, when it is less than 0 we just ingore it.
Also we use qemu_opt_get() to get 'splash-time', then convert it to a number
ourselves. This is wrong. This patch does following:
1. use qemu_opt_get_number() to parse
Currently the user can set a negative reboot_timeout.
Also it is wrong to parse 'reboot-timeout' with qemu_opt_get() and then
convert it to number. This patch refactor this function by following:
1. ensure reboot_timeout is in 0~0x
2. use qemu_opt_get_number() to parse reboot_timeout
3.
This patchset comes out as the result of the following review as per
Markus's and Gerd's advice:
-->https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg06975.html
-->http://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00701.html
The second patch also fix that the user can set a negative
On 11/8/2018 6:21 AM, Richard Henderson wrote:
On 11/7/18 7:48 PM, Bijan Mottahedeh wrote:
+static void set_system_clock_scale(void)
+{
+unsigned long cntfrq_el0;
+
+asm volatile("mrs %0, cntfrq_el0" : "=r"(cntfrq_el0));
+
+if (cntfrq_el0 == 0) {
+cntfrq_el0 =
On 11/09/2018 12:57 PM, Eric Blake wrote:
> On 9/27/18 12:23 PM, John Snow wrote:
>>
>>
>> On 09/26/2018 11:11 PM, Eric Blake wrote:
>>> We need an accurate count of the number of bits set in a bitmap
>>> after a merge. In particular, since the merge operation short-circuits
>>> a merge from an
On 8/9/18 5:31 PM, Max Reitz wrote:
There is no reason why the constraints we put on @replaces should be
limited to drive-mirror. Therefore, move the sanity checks from
qmp_drive_mirror() to blockdev_mirror_common() so they apply to
blockdev-mirror as well.
Signed-off-by: Max Reitz
---
On 8/9/18 5:31 PM, Max Reitz wrote:
Note 1: This series depends on v10 of my “block: Fix some filename
generation issues” series.
Based-on: <20180809213528.14738-1-mre...@redhat.com>
Note 2: This is technically the first part of my active mirror followup.
But just very technically. I noticed
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1541764187-10732-1-git-send-email-yu.c.zh...@linux.intel.com
Subject: [Qemu-devel] [PATCH v1 0/3] intel-iommu: add support for 5-level
virtual IOMMU.
=== TEST SCRIPT BEGIN
The initial goal of this RFC is to get feedback on tests not specific
to the QEMU main binary, but specific to other components such as
qemu-img.
For this experiment, a small issue with the zero and negative number
of I/O operations given to the bench command was chosen.
Cleber Rosa (2):
Testing other utilities such as qemu-img do not require the same
infrastructure that testing QEMU itself does. Let's add a base class
that just sets the suitable qemu-img binary to be used during test.
Signed-off-by: Cleber Rosa
---
tests/acceptance/avocado_qemu/__init__.py | 20
It's debatable whether it makes sense to consider the bench command
successful when no I/O requests will be performed. This changes the
behavior to consider a zero count of I/O requests an invalid value.
While at it, avoid using signed types for number of I/O requests.
The image file used, is a
On Fri, Nov 9, 2018 at 11:21 AM Palmer Dabbelt wrote:
>
> Our current fence implementation ignores fences for the user-only
> configurations. This is incorrect but unlikely to manifest: it requires
> multi-threaded user-only code that takes advantage of the weakness in
> the host's memory model
On Fri, Nov 09, 2018 at 10:07:10AM -0500, Cleber Rosa wrote:
> The "check" target is not a target that will run all other tests
> listed, so in order to be accurate it's necessary to list those that
> will run. The same is true for "check-clean".
>
> Then, to give a better visual impression of
On Fri, Nov 09, 2018 at 10:07:08AM -0500, Cleber Rosa wrote:
> The current approach works fine, but it runs Python on every make
> command (even if it's not related to the venv usage).
>
> This is just an optimization, and not a change of behavior.
>
> Signed-off-by: Cleber Rosa
Reviewed-by:
On Fri, Nov 09, 2018 at 10:07:07AM -0500, Cleber Rosa wrote:
> Some functionality is dependent on the Python version
> detected/configured on configure. While it's possible to run the
> Python version later and check for the version, doing it once is
> preferable. Also, it's a relevant
On 09/11/2018 15:14, Gerd Hoffmann wrote:
> Broken (segfaultson first keypress) and appearently unused.
>
> Signed-off-by: Gerd Hoffmann
No objection, but can we make some effort of, at least, putting the
stack backtrace in the commit log?
Paolo
> ---
> include/hw/bt.h | 3 -
>
On 11/9/18 5:40 AM, Li Zhijian wrote:
> Just noticed that there is a field xloadflags at recent protocol
> 60 Protocol 2.12: (Kernel 3.8) Added the xloadflags field and
> extension fields
> 61 to struct boot_params for loading bzImage and ramdisk
> 62 above
Simplify net_socket_send(), avoid extra buf/buf1 variable, and
backwards goto.
Signed-off-by: Marc-André Lureau
---
net/socket.c | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index c92354049b..8a9c30892d 100644
---
This adds tests for SMP option, by passing -smp with
various combinations of cpus, cores, threads, and sockets
values it checks that invalid topologies are not accepted
as well as missing values are correctly calculated.
Signed-off-by: Wainer dos Santos Moschetta
---
-net socket has a fd argument, and may be passed pre-opened sockets.
TCP sockets use framing.
UDP sockets have datagram boundaries.
When given a unix dgram socket, it will be able to read from it, but
will attempt to send on the dgram_dst, which is unset. The other end
will not receive the data.
On 11/9/18 1:25 PM, Eduardo Habkost wrote:
>>
>> "Python -V" is quite different from "sys.version". Indeed it includes
>> the "Python " prefix, but that's all, everything else is the version number.
>
> Is this a guarantee documented somewhere?
>
Oops, looks like I missed that comment, and
On 11/9/18 2:34 PM, Philippe Mathieu-Daudé wrote:
> On 9/11/18 16:07, Cleber Rosa wrote:
>> For the two Python jobs, which seem to have the goal of making sure
>> QEMU builds successfully on the 3.0-3.6 spectrum of Python 3 versions,
>> the specified version is only applicable if a Python
Cc'ing Andrzej, the actual author.
On 9/11/18 15:14, Gerd Hoffmann wrote:
Broken (segfaultson first keypress) and appearently unused.
Signed-off-by: Gerd Hoffmann
---
include/hw/bt.h | 3 -
hw/bt/hid.c | 554
vl.c
On 9/11/18 16:07, Cleber Rosa wrote:
For the two Python jobs, which seem to have the goal of making sure
QEMU builds successfully on the 3.0-3.6 spectrum of Python 3 versions,
the specified version is only applicable if a Python virtual
environment is used. To do that, it's necessary to define
On 9/11/18 16:07, Cleber Rosa wrote:
The "check" target is not a target that will run all other tests
listed, so in order to be accurate it's necessary to list those that
will run. The same is true for "check-clean".
Then, to give a better visual impression of the differences in the
various
Our current fence implementation ignores fences for the user-only
configurations. This is incorrect but unlikely to manifest: it requires
multi-threaded user-only code that takes advantage of the weakness in
the host's memory model and can be inlined by TCG.
This patch simply treats fences the
I'd like to target this for 3.1: while it's a pretty esoteric bug the
risk of breaking anything is low and tracking down a manifestation of
the bug would be a nightmare.
I don't think the performance improvement alluded to will be a 3.1
candidiate, and as a result I probably won't get around to
On Fri, Nov 09, 2018 at 11:10:21AM +0100, Paolo Bonzini wrote:
> On 08/11/2018 22:00, Eduardo Habkost wrote:
> > Understood. My interpretation of "target" was just "a QEMU
> > binary". In other words, I thought we were talking about
> > anything that could be compiled in/out from a specific QEMU
On 11/9/18 1:25 PM, Eduardo Habkost wrote:
> On Fri, Nov 09, 2018 at 11:39:32AM -0500, Cleber Rosa wrote:
>>
>>
>> On 11/9/18 10:49 AM, Eduardo Habkost wrote:
>>> On Fri, Nov 09, 2018 at 10:07:07AM -0500, Cleber Rosa wrote:
Some functionality is dependent on the Python version
On Fri, 09 Nov 2018 02:53:45 PST (-0800), Peter Maydell wrote:
On 8 November 2018 at 18:52, Palmer Dabbelt wrote:
On Thu, 08 Nov 2018 10:38:51 PST (-0800), alistai...@gmail.com wrote:
On Thu, Nov 8, 2018 at 10:35 AM Palmer Dabbelt wrote:
The following changes since commit
On 9 November 2018 at 14:14, Gerd Hoffmann wrote:
> Broken (segfaultson first keypress) and appearently unused.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/hw/bt.h | 3 -
> hw/bt/hid.c | 554
>
> vl.c| 34
Hello everyone,
This is a cross-list post, and a cross-community invitation for a
regular meeting about QEMU testing automation, Avocado's role in that,
CI efforts and related topics.
The meetings will take place every Tuesday from 6:00 AM to 7:00 AM,
(GMT-05:00) Eastern Time - New York.
The
On Fri, Nov 09, 2018 at 11:39:32AM -0500, Cleber Rosa wrote:
>
>
> On 11/9/18 10:49 AM, Eduardo Habkost wrote:
> > On Fri, Nov 09, 2018 at 10:07:07AM -0500, Cleber Rosa wrote:
> >> Some functionality is dependent on the Python version
> >> detected/configured on configure. While it's possible
QEMU used to exits with a not accurate error message when
an initrd > 2GiB was passed. That was fixed on patch:
commit f3839fda5771596152b75dd1e1a6d050e6e6e380
Author: Li Zhijian
Date: Thu Sep 13 18:07:13 2018 +0800
change get_image_size return type to int64_t
On Thu, Nov 08, 2018 at 11:15:23AM +, Stefan Hajnoczi wrote:
> v4:
> * Once more, with feeling! Fix 'https//' in get_maintainer.pl [Philippe]
> v3:
> * Fix broken openhackware URL [Eric]
> * Convert a few remaining URLs [Eric]
> v2:
> * Use HTTPS for repo.or.cz [Eric]
>
> Jeff Cody has
On 9 November 2018 at 17:35, Peter Maydell wrote:
> Hyp mode is an exception to the general rule that each AArch32
> mode has its own r13, r14 and SPSR -- it has a banked r13 and
> SPSR but shares its r14 with User and System mode. We were
> incorrectly implementing it as banked, which meant that
Looks good to me. Some comments below
On Fri, Nov 09, 2018 at 04:58:27PM +0200, Yuri Benditovich wrote:
> This commit adds implementation of RX packets
> coalescing, compatible with requirements of Windows
> Hardware compatibility kit.
>
> The device enables feature VIRTIO_NET_F_RSC_EXT in
>
On 08.11.18 13:43, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> Hi Markus,
>>
>>
>> Le jeu. 8 nov. 2018 09:46, Markus Armbruster a écrit :
>>
>>> Cleber Rosa writes:
>>>
On 11/7/18 1:05 AM, Markus Armbruster wrote:
> [...]
> PEP 394 recommends software distributions
On 9/27/18 12:23 PM, John Snow wrote:
On 09/26/2018 11:11 PM, Eric Blake wrote:
We need an accurate count of the number of bits set in a bitmap
after a merge. In particular, since the merge operation short-circuits
a merge from an empty source, if you have bitmaps A, B, and C where
B started
On 9 November 2018 at 17:19, Corey Minyard wrote:
> On 11/9/18 9:02 AM, Peter Maydell wrote:
>> The data provided by the caller is only the initialization
>> data. So I think the device should create its own memory
>> to copy that init data into, and migrate that ram, not
>> wherever the
The Cortex-A15 and Cortex-A7 both have EL2; now we've implemented
it properly we can enable the feature bit.
Signed-off-by: Peter Maydell
---
target/arm/cpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 784a4c2dfcc..b7185234d85 100644
---
On 11/9/18 9:02 AM, Peter Maydell wrote:
On 9 November 2018 at 14:56, Corey Minyard wrote:
On 11/8/18 12:03 PM, Peter Maydell wrote:
On 8 November 2018 at 17:58, Corey Minyard wrote:
On 11/8/18 8:08 AM, Peter Maydell wrote:
This doesn't do anything for migration of the actual data
After iov_discard_front(), the iov may be smaller than its initial
size. Fixes the heap-buffer-overflow spotted by ASAN:
==9036==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x606001e0
at pc 0x7fe632eca3f0 bp 0x7ffddc4a05a0 sp 0x7ffddc49fd48
WRITE of size 32 at 0x606001e0
Changes in v10:
- added qemu_register_wakeup_support call in hw/i386/xen/xen-hvm.c
- explained the effects of not checking the query-current-machine
before issuing guest-suspend-ram/hybrid in QGA documentation
- changed qemu_system_wakeup_request to allow the runstate check
error to be propagated
Hyp mode is an exception to the general rule that each AArch32
mode has its own r13, r14 and SPSR -- it has a banked r13 and
SPSR but shares its r14 with User and System mode. We were
incorrectly implementing it as banked, which meant that on
entry to Hyp mode r14 was 0 rather than the USR/SYS
This patchset fixes the last serious bug in our implementation
of Hyp mode (aka EL2 for AArch32), and turns the feature bit
on for the Cortex-A7 and Cortex-A15 CPUs.
The bug is that Hyp mode is an exception to the previous
general rule that every AArch32 mode (except SYS, which
always shares with
The qmp/hmp command 'system_wakeup' is simply a direct call to
'qemu_system_wakeup_request' from vl.c. This function verifies if
runstate is SUSPENDED and if the wake up reason is valid before
proceeding. However, no error or warning is thrown if any of those
pre-requirements isn't met. There is
This patch updates the descriptions of 'guest-suspend-ram' and
'guest-suspend-hybrid' to mention that both commands relies now
on the proper support for wake up from suspend, retrieved by the
'wakeup-suspend-support' attribute of the 'query-current-machine'
QMP command.
Reported-by: Balamuruhan S
When issuing the qmp/hmp 'system_wakeup' command, what happens in a
nutshell is:
- qmp_system_wakeup_request set runstate to RUNNING, sets a wakeup_reason
and notify the event
- in the main_loop, all vcpus are paused, a system reset is issued, all
subscribers of wakeup_notifiers receives a
On 11/9/18 10:56 AM, Emilio G. Cota wrote:
> On Fri, Nov 09, 2018 at 10:30:01 -0500, Cleber Rosa wrote:
>> To be fully honest, this may not be a OSX (alone) condition, but may
>> be a situation that only happens with OSX on Travis-CI, were resources
>> are quite limited.
>>
>> I have personal
On 11/9/18 10:34 AM, Peter Maydell wrote:
> On 9 November 2018 at 15:30, Cleber Rosa wrote:
>> To be fully honest, this may not be a OSX (alone) condition, but may
>> be a situation that only happens with OSX on Travis-CI, were resources
>> are quite limited.
>>
>> I have personal experience
On Fri, 9 Nov 2018, Aleksandar Markovic wrote:
> > > I think that the best solution that you exclude DDIV, DDIVU, DMULT, DMULTU
> > > in a separate patch - there is no document to support their inclusion.
> >
> > As Maciej noted, the 64-bit MIPS Linux psABI is indivisible, so how could
> > your
On 11/9/18 9:07 AM, Cleber Rosa wrote:
The "check" target is not a target that will run all other tests
listed, so in order to be accurate it's necessary to list those that
will run. The same is true for "check-clean".
Then, to give a better visual impression of the differences in the
various
Ok then, keeping an eye out for the eventual acceptance in the official
repo, so that I can change the bug report status.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1795527
Title:
Malformed
On 11/9/18 10:49 AM, Eduardo Habkost wrote:
> On Fri, Nov 09, 2018 at 10:07:07AM -0500, Cleber Rosa wrote:
>> Some functionality is dependent on the Python version
>> detected/configured on configure. While it's possible to run the
>> Python version later and check for the version, doing it
On 11/9/18 8:14 AM, Gerd Hoffmann wrote:
Broken (segfaultson first keypress) and appearently unused.
s/segfaultson/segfaults on/, s/appearently/apparently/
Also, trailing '.' in the subject line is unusual
Signed-off-by: Gerd Hoffmann
---
--
Eric Blake, Principal Software Engineer
Red
On Fri, 9 Nov 2018, Laurent Vivier wrote:
> > I believe MIPS64 Debian is all n32.
>
> Some readelf results:
>
> mips64el/stretch
>
> Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF64
> Flags: 0x8007, noreorder, pic, cpic, mips64r2
Hmm, that's weird --
This is needed to build skiboot from tarball-distributed sources
since the git data the make_release.sh script relies on to generate
it is not available.
Cc: qemu-sta...@nongnu.org
Reported-by: Michael Tokarev
Signed-off-by: Michael Roth
---
scripts/make-release | 1 +
1 file changed, 1
When building qemu-ga for w32 with VSS support, some parts of qemu-ga
are not linked against glib, specifically the C++ bits used to
create the VSS provider DLL. With 3ebee3b191e, we now define assert()
as g_assert() for all mingw32 builds via osdep.h, which results in the
following build
On Fri, Nov 09, 2018 at 10:30:01 -0500, Cleber Rosa wrote:
> To be fully honest, this may not be a OSX (alone) condition, but may
> be a situation that only happens with OSX on Travis-CI, were resources
> are quite limited.
>
> I have personal experience with tests that exercise parallelism or
>
Cleber Rosa writes:
> For the two Python jobs, which seem to have the goal of making sure
> QEMU builds successfully on the 3.0-3.6 spectrum of Python 3 versions,
> the specified version is only applicable if a Python virtual
> environment is used. To do that, it's necessary to define the
>
On Fri, Nov 09, 2018 at 10:07:07AM -0500, Cleber Rosa wrote:
> Some functionality is dependent on the Python version
> detected/configured on configure. While it's possible to run the
> Python version later and check for the version, doing it once is
> preferable. Also, it's a relevant
Alex Bennée writes:
> Hi,
>
> I missed a fix I'd applied locally from v2 so this is a resend with
> some additional tags, some changes suggested by rth and one more fix
> for the test case.
>
> So these are fixes for guest debug when running under KVM. While
> re-spinning these I came across
On 9 November 2018 at 15:30, Cleber Rosa wrote:
> To be fully honest, this may not be a OSX (alone) condition, but may
> be a situation that only happens with OSX on Travis-CI, were resources
> are quite limited.
>
> I have personal experience with tests that exercise parallelism or
> depend on
> From: Fredrik Noring
> Subject: Re: [PATCH v2 4/6] target/mips: Fix decoding mechanism of special
> R5900 opcodes
>
> Hi Aleksandar,
>
> > Tx79 mentions the opposite: that DDIV, DDIVU, DMULT, DMULTU are not
> > included in R5900 set.
> >
> > I think that the best solution that you exclude
The OSX jobs were timing out on Travis, due to the long time they need
to run tests with all targets. Let's break them down to avoid hitting
the time limit, and at the same time, give faster results.
Additionally the qtest based tests were hanging intermittently. The
first debugging attempt
The OS X jobs on Travis fail for a number of reasons. This is an
attempt to decide its faith, either as something that will be kept on
the configuration (and properly maintained), removed, or maybe active
but with failures waived (Travis allows for that).
The result of this can be seen in these
To be fully honest, this may not be a OSX (alone) condition, but may
be a situation that only happens with OSX on Travis-CI, were resources
are quite limited.
I have personal experience with tests that exercise parallelism or
depend on timing to fail on Travis. Because I'm not 100% certain that
Under heavy IO (e.g. fio) the queue is not checked frequently enough for
pending commands. As a result some pending commands are timed out by the
linux sym53c8xx driver, which sends SCSI Abort messages for the timed out
commands. The SCSI Abort messages result in linux errors, which show up
on the
It turns out symbol resolution isn't enough as modern kernels are
often padded with check code at the start of functions. GDB seems to
put the breakpoint at the first non-check instruction which causes
comparisons with the symbol resolution to fail.
For normal breakpoints we can detect the hit
We already have this symbol defined so lets use it.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
---
target/arm/cpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index b5eff79f73..1efff21a18 100644
--- a/target/arm/cpu.h
Hi,
I missed a fix I'd applied locally from v2 so this is a resend with
some additional tags, some changes suggested by rth and one more fix
for the test case.
So these are fixes for guest debug when running under KVM. While
re-spinning these I came across an anomaly which pointed to a kernel
When we are debugging the guest all exceptions come our way but might
be for the guest's own debug exceptions. We use the ->do_interrupt()
infrastructure to inject the exception into the guest. However, we are
missing a full setup of the exception structure, causing an assert
later down the line.
The test was incomplete and incorrectly caused debug exceptions to be
generated when returning to EL2 after a failed attempt to single-step
an EL1 instruction. Fix this while cleaning up the function a little.
Signed-off-by: Alex Bennée
---
v3
- further re-arrangement as suggested by rth
---
Fix the assertion failure when running interrupts.
Signed-off-by: Alex Bennée
Reviewed-by: Peter Maydell
Reviewed-by: Richard Henderson
---
target/arm/kvm64.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 6351a54b28..c39150e5e1 100644
---
You should declare you are using a global version of a variable before
you attempt to modify it in a function.
Signed-off-by: Alex Bennée
Reviewed-by: Peter Maydell
Reviewed-by: Richard Henderson
---
tests/guest-debug/test-gdbstub.py | 1 +
1 file changed, 1 insertion(+)
diff --git
This only fails with some (broken) versions of gdb but we should
treat the top bits of DBGBVR as RESS. Properly sign extend QEMU's
reference copy of dbgbvr and also update the register descriptions in
the comment.
Signed-off-by: Alex Bennée
---
v2
- sanitise register on insertion
- update
For the two Python jobs, which seem to have the goal of making sure
QEMU builds successfully on the 3.0-3.6 spectrum of Python 3 versions,
the specified version is only applicable if a Python virtual
environment is used. To do that, it's necessary to define the
(primary?) language of the job to
The "check" target is not a target that will run all other tests
listed, so in order to be accurate it's necessary to list those that
will run. The same is true for "check-clean".
Then, to give a better visual impression of the differences in the
various targets, let's add empty lines.
Finally,
Some functionality is dependent on the Python version
detected/configured on configure. While it's possible to run the
Python version later and check for the version, doing it once is
preferable. Also, it's a relevant information to keep in build logs,
as the overall behavior of the build can be
The current approach works fine, but it runs Python on every make
command (even if it's not related to the venv usage).
This is just an optimization, and not a change of behavior.
Signed-off-by: Cleber Rosa
---
tests/Makefile.include | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
A recent experience with Travis-CI[1] showed that some tests were not
running with the intended Python version. Let's add the Python
version the configure output, which serves as a general debugging
aid that the intended Python version was used[2][3].
Additionally, the recently introduced
On 9 November 2018 at 14:56, Corey Minyard wrote:
> On 11/8/18 12:03 PM, Peter Maydell wrote:
>>
>> On 8 November 2018 at 17:58, Corey Minyard wrote:
>>>
>>> On 11/8/18 8:08 AM, Peter Maydell wrote:
This doesn't do anything for migration of the actual data contents.
The current
This commit adds implementation of RX packets
coalescing, compatible with requirements of Windows
Hardware compatibility kit.
The device enables feature VIRTIO_NET_F_RSC_EXT in
host features if it supports extended RSC functionality
as defined in the specification.
This feature requires at least
On 11/8/18 12:03 PM, Peter Maydell wrote:
On 8 November 2018 at 17:58, Corey Minyard wrote:
On 11/8/18 8:08 AM, Peter Maydell wrote:
This doesn't do anything for migration of the actual data contents.
The current users of this device (hw/arm/aspeed.c and the
smbus_eeprom_init() function)
On 09/11/2018 15:14, Maciej W. Rozycki wrote:
> On Fri, 9 Nov 2018, Laurent Vivier wrote:
>
>> if you have time, o32 & n32 support needs to be reworked.
>>
>> We have two binaries qemu-mips and qemu-mipsn32 sharing the same ELF
>> mask/magic.
>>
>> As n32 identifies a kernel ABI version, we
On 09/11/2018 14:14, Gerd Hoffmann wrote:
Broken (segfaultson first keypress) and appearently unused.
s/segfaultson/segfaults on/
s/appearently/apparently/
Signed-off-by: Gerd Hoffmann
one question at the end, otherwise
Reviewed-by: Liam Merwick
---
include/hw/bt.h | 3 -
https://patchwork.ozlabs.org/patch/995566/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1795527
Title:
Malformed audio and video output stuttering after upgrade to QEMU 3.0
Status in QEMU:
New
Quoting Peter Maydell (2018-11-08 06:52:23)
> The guest-agent-core.h header was missing the usual guards
> against multiple inclusion; add them.
>
> (Spotted by lgtm.com's static analyzer.)
>
> Signed-off-by: Peter Maydell
Thanks, applied to qga tree:
Quoting Marc-André Lureau (2018-11-03 08:01:43)
> Introduced in commit b1ba8890e63ce9432c41c5c3fc229f54c87c9c99, vol_h
> handle should be closed, and "out" cleanup should be done after
> DeviceIoControl() fails.
>
> Signed-off-by: Marc-André Lureau
Thanks, applied to qga tree:
> From: Fredrik Noring
> Subject: Re: [PATCH v2 4/6] target/mips: Fix decoding mechanism of special
> R5900 opcodes
>
> Hi Aleksandar,
>
> > Tx79 mentions the opposite: that DDIV, DDIVU, DMULT, DMULTU are not
> > included in R5900 set.
> >
> > I think that the best solution that you exclude
Hi Aleksandar,
> Tx79 mentions the opposite: that DDIV, DDIVU, DMULT, DMULTU are not
> included in R5900 set.
>
> I think that the best solution that you exclude DDIV, DDIVU, DMULT, DMULTU
> in a separate patch - there is no document to support their inclusion.
As Maciej noted, the 64-bit MIPS
On Mon, 5 Nov 2018 02:40:32 +0100
Samuel Ortiz wrote:
> The PCI hole properties are not pc or i386 specific. They belong to the
> PCI host header instead.
>
> Signed-off-by: Samuel Ortiz
> ---
> include/hw/i386/pc.h | 5 -
> include/hw/pci/pci_host.h | 6 ++
> 2 files changed, 6
On Mon, 5 Nov 2018 02:40:25 +0100
Samuel Ortiz wrote:
> This is going to be needed by the Hardware-reduced ACPI routines.
>
> Reviewed-by: Philippe Mathieu-Daudé
> Tested-by: Philippe Mathieu-Daudé
> Signed-off-by: Samuel Ortiz
the patch is probably misplaced withing series,
if there is an
On Mon, 5 Nov 2018 02:40:24 +0100
Samuel Ortiz wrote:
> ACPI tables are platform and machine type and even architecture
> agnostic, and as such we want to provide an internal ACPI API that
> only depends on platform agnostic information.
>
> For the x86 architecture, in order to build ACPI
> From: Fredrik Noring
> Subject: Re: [PATCH v2 4/6] target/mips: Fix decoding mechanism of special
> R5900 opcodes
>
> >
> > Could you please provide a document that would justify inclusion of these
> > non-R5900 instruction in an R5900 emulation?
>
> Would you accept the TX79 manual
The rate of pulseaudio absorbing the audio stream is used to control the
the rate of the guests audio stream. When the emulated hardware uses
small chunks (like intel-hda does) we need small chunks on the audio
backend side too, otherwise that feedback loop doesn't work very well.
Cc: Max
On Fri, 9 Nov 2018, Laurent Vivier wrote:
> if you have time, o32 & n32 support needs to be reworked.
>
> We have two binaries qemu-mips and qemu-mipsn32 sharing the same ELF
> mask/magic.
>
> As n32 identifies a kernel ABI version, we should have only one binary
> for qemu-mips and
Broken (segfaultson first keypress) and appearently unused.
Signed-off-by: Gerd Hoffmann
---
include/hw/bt.h | 3 -
hw/bt/hid.c | 554
vl.c| 34 +---
hw/bt/Makefile.objs | 3 +-
qemu-options.hx | 9 -
5
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20181106110548.4209-1-luc.mic...@greensocs.com
Subject: [Qemu-devel] [PATCH v4 00/16] gdbstub: support for the multiprocess
extension
=== TEST SCRIPT BEGIN ===
#!/bin/bash
1 - 100 of 180 matches
Mail list logo
