The following changes since commit 5e7bcdcfe69ce0fad66012b2cfb2035003c37eef:
display/bochs: fix pcie support (2019-08-12 16:36:41 +0100)
are available in the Git repository at:
git://github.com/dgibson/qemu.git tags/ppc-for-4.1-20190813
for you to fetch changes up to
Hello again,
I have tried to disable TrustZone using argument mentioned in comment #5
by changing -M sabrelite to -M sabrelite,secure=off, but I get error
"qemu-system-arm: Property '.secure' not found". It works with virt
though. Is there any other way to disable it?
Thank you,
...
--
You rece
Patchew URL: https://patchew.org/QEMU/20190813064853.29310-1-...@kaod.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH] spapr/xive: Fix migration of hot-plugged CPUs
Message-id: 20190813064853.29310-1-...@kaod.or
On Monday 12 August 2019 03:38 PM, David Gibson wrote:
> On Mon, Aug 05, 2019 at 02:14:39PM +0530, Aravinda Prasad wrote:
>> Alexey/David,
>>
>> With the SLOF changes, QEMU cannot resize the RTAS blob. Resizing is
>> required for FWNMI support which extends the RTAS blob to include an
>> error l
On 30/07/2019 15:45, Rashmica Gupta wrote:
The AST2600 has the same sets of 3.6v gpios as the AST2400 plus an
addtional two sets of 1.8V gpios.
Signed-off-by: Rashmica Gupta
---
hw/gpio/aspeed_gpio.c | 186 +-
include/hw/gpio/aspeed_gpio.h | 2 +-
ping^2
2019年8月6日(火) 0:38 Hikaru Nishida :
> ping...
>
> 2019年7月20日(土) 15:04 :
>
>> From: Hikaru Nishida
>>
>> This commit adds No Op Command (23) to xHC for verifying the operation
>> of the Command Ring mechanisms.
>> No Op Command is defined in XHCI spec (4.6.2) and just reports Command
>> Com
On 13/08/19 08:17, Thomas Huth wrote:
> On 8/12/19 9:16 PM, John Snow wrote:
>>
>>
>> On 7/25/19 4:34 AM, Thomas Huth wrote:
>>> On 24/07/2019 18.29, Paolo Bonzini wrote:
On 24/07/19 11:34, Thomas Huth wrote:
> In case somebody is interested, two of the "auto" iotests are failing
> on
On 13/08/19 08:29, Jan Kiszka wrote:
> Based on SDM from May 2019.
>
> Signed-off-by: Jan Kiszka
> ---
> scripts/kvm/vmxcap | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/scripts/kvm/vmxcap b/scripts/kvm/vmxcap
> index 99a8146aaa..d8c7d6dfb8 100755
> --- a/scripts/kvm/vmxcap
>
On 13/08/19 08:44, Thomas Huth wrote:
> Maybe s/Each struct/Each global struct/ ? Or "non-local" or something
> similar? Sometimes, you also define a struct just within a function, and
> in that case we don't require the typedef, do we?
I changed it to "each named struct" and queued.
Thanks,
Pao
12.08.2019 22:50, Max Reitz wrote:
> On 12.08.19 21:46, Max Reitz wrote:
>> On 12.08.19 20:11, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all!
>>>
>>> I'm not sure, is it a bug or a feature, but using qcow2 under raw is
>>> broken. It should be either fixed like I propose (by Max's suggestion)
>>>
On 2019/8/12 下午3:45, Peter Xu wrote:
This is a RFC series.
The VT-d code has some defects, one of them is that we cannot detect
the misuse of vIOMMU and vfio-pci early enough.
For example, logically this is not allowed:
-device intel-iommu,caching-mode=off \
-device vfio-pci,host=05:00
On 7/30/19 3:23 PM, Andrey Shinkevich wrote:
>
>
> On 30/07/2019 15:59, Thomas Huth wrote:
>> On 30/07/2019 14.52, Thomas Huth wrote:
>>> On 29/07/2019 14.46, Andrey Shinkevich wrote:
This patch is to reduce the number of Valgrind report messages about
using uninitialized memory with th
On 8/5/19 5:24 AM, Oleinik, Alexander wrote:
> The number of queues is 2n+1, where n == 1 when multiqueue is disabled
>
> Signed-off-by: Alexander Oleinik
> ---
>
> I split this commit out of the fuzz patch-series.
>
> tests/libqos/virtio-net.c | 1 +
> tests/libqos/virtio-net.h | 2 +-
> 2 fi
On 8/5/19 5:13 AM, Oleinik, Alexander wrote:
> Both the qtest client, libqtest.c, and server, qtest.c, used the same
> name for initialization functions which can cause confusion.
>
> Signed-off-by: Alexander Oleinik
> ---
> Thank you, Thomas Huth for the suggestion.
Thanks you for the patch, it
Hi Igor and Eduardo,
I am wondering if there are more comments about patch 1/11~4/11? Because
these 4 patch are independent and the patch series are big and pushing
for a long time. Could the patch 1/11~4/11 be ready for queuing firstly?
If there is anything else need me to do about this seri
13.08.2019 11:39, Vladimir Sementsov-Ogievskiy wrote:
> 12.08.2019 22:50, Max Reitz wrote:
>> On 12.08.19 21:46, Max Reitz wrote:
>>> On 12.08.19 20:11, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
I'm not sure, is it a bug or a feature, but using qcow2 under raw is
broken. It sh
Simplifies sending security patches to all people listed in
https://wiki.qemu.org/SecurityProcess. Should also make it
harder to send a copy to the mailing list by accident.
Signed-off-by: Gerd Hoffmann
---
.gitpublish | 12
1 file changed, 12 insertions(+)
diff --git a/.gitpublis
Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Check that it is fixed by previous commit
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/263 | 46 ++
> tests/qemu-iotests/263.out | 12 ++
> tests/q
13.08.2019 12:10, Kevin Wolf wrote:
> Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> Check that it is fixed by previous commit
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>> ---
>> tests/qemu-iotests/263 | 46 ++
>> tests/qe
emu.git tags/ppc-for-4.1-20190813
>
> for you to fetch changes up to 310cda5b5e9df642b19a0e9c504368ffba3b3ab9:
>
> spapr/xive: Fix migration of hot-plugged CPUs (2019-08-13 16:50:30 +1000)
>
>
> ppc patch
That property doesn't exist for the sabrelite board, it's only on some
of the others like vexpress or virt.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1839807
Title:
Snapshots freeze guest Sabre
While global_qtest and its wrapper functions work fine for tests that only
run one instance of QEMU, using the global_qtest variable in our qtests is
very problematic for tests that use multiple test states (e.g. migration
tests). Thus the core libqtest and libqos library functions should not
depen
No test is using hmp() anymore, and since this function uses the disliked
global_qtest variable, we should also make sure that nobody adds new code
with this function again. qtest_hmp() should be used instead.
Signed-off-by: Thomas Huth
---
tests/libqtest.c | 11 ---
tests/libqtest.h | 1
The libqos library functions should never depend on global_qtest,
since these functions might be used in tests that track multiple
test states. So let's use the test state of the QPCIDevice instead.
Signed-off-by: Thomas Huth
---
tests/libqos/virtio-pci.c | 8
1 file changed, 4 insertio
The normal libqtest library functions should never depend on global_qtest.
Pass in the test state via parameter instead. And while we're at it,
also rename this function to qtest_qmp_assert_success() to make it clear
that it is part of libqtest.
Signed-off-by: Thomas Huth
---
tests/libqtest.c
The libqos library functions should never depend on global_qtest,
since these functions might be used in tests that track multiple
test states. Pass around a pointer to the QTestState instead.
Signed-off-by: Thomas Huth
---
tests/libqos/virtio.c| 74 ++-
tests/libqos/virtio.
Generic library functions like qtest_qmp_device_add() and _del()
should not depend on the global_qtest variable. Pass the test
state via parameter instead.
Signed-off-by: Thomas Huth
---
tests/cpu-plug-test.c | 15 +--
tests/e1000e-test.c| 2 +-
tests/ivshmem-test.c
The generic libqtest library functions should not use functions that
require the global_qtest variable.
Signed-off-by: Thomas Huth
---
tests/libqtest.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/libqtest.c b/tests/libqtest.c
index 3e9245d4c9..d1aead30ed 1006
Am 12.08.2019 um 21:46 hat Max Reitz geschrieben:
> On 12.08.19 20:11, Vladimir Sementsov-Ogievskiy wrote:
> > Hi all!
> >
> > I'm not sure, is it a bug or a feature, but using qcow2 under raw is
> > broken. It should be either fixed like I propose (by Max's suggestion)
> > or somehow forbidden (j
13.08.2019 12:01, Vladimir Sementsov-Ogievskiy wrote:
> 13.08.2019 11:39, Vladimir Sementsov-Ogievskiy wrote:
>> 12.08.2019 22:50, Max Reitz wrote:
>>> On 12.08.19 21:46, Max Reitz wrote:
On 12.08.19 20:11, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> I'm not sure, is it a bug
Am 13.08.2019 um 11:22 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 13.08.2019 12:10, Kevin Wolf wrote:
> > Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >> Check that it is fixed by previous commit
> >>
> >> Signed-off-by: Vladimir Sementsov-Ogievskiy
> >> ---
> >> t
On Tue, 13 Aug 2019 08:45:49 +0200
Jens Freimann wrote:
> On Mon, Aug 12, 2019 at 03:22:52PM -0600, Alex Williamson wrote:
> >On Mon, 12 Aug 2019 17:18:54 +0200
> >Cornelia Huck wrote:
> >
> >> On Fri, 2 Aug 2019 17:05:59 +0200
> >> Jens Freimann wrote:
> >>
> >> > As usual block all vfio-
+-- On Fri, 9 Aug 2019, P J P wrote --+
| From: Prasad J Pandit
|
| When executing script in lsi_execute_script(), the LSI scsi
| adapter emulator advances 's->dsp' index to read next opcode.
| This can lead to an infinite loop if the next opcode is empty.
| Exit such loop after reading 10k empty
On 7/9/19 9:32 AM, Thomas Huth wrote:
> The NeXTcube uses a linear framebuffer with 4 greyscale colors and
> a fixed resolution of 1120 * 832.
> This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
>
> https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-fb.c
>
> and alte
On 13/08/2019 11:46, Thomas Huth wrote:
> On 7/30/19 3:23 PM, Andrey Shinkevich wrote:
>>
>>
>> On 30/07/2019 15:59, Thomas Huth wrote:
>>> On 30/07/2019 14.52, Thomas Huth wrote:
On 29/07/2019 14.46, Andrey Shinkevich wrote:
> This patch is to reduce the number of Valgrind report messag
On 7/9/19 9:32 AM, Thomas Huth wrote:
> It is likely still quite incomplete (e.g. mouse and interrupts are not
> implemented yet), but it is good enough for keyboard input at the firmware
> monitor.
> This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
>
> https://github.com/bla
On Tue, 9 Jul 2019 at 08:35, Thomas Huth wrote:
>
> The NeXTcube uses a linear framebuffer with 4 greyscale colors and
> a fixed resolution of 1120 * 832.
> This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
>
> https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-fb.c
>
On Tue, 9 Jul 2019 at 08:35, Thomas Huth wrote:
>
> It is likely still quite incomplete (e.g. mouse and interrupts are not
> implemented yet), but it is good enough for keyboard input at the firmware
> monitor.
> This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
>
> https://gi
On Thu, Jul 18, 2019 at 09:34:41PM +0200, Stefan Weil wrote:
> Signed-off-by: Stefan Weil
Added to audio queue.
thanks,
Gerd
On 7/9/19 9:32 AM, Thomas Huth wrote:
> It is still quite incomplete (no SCSI, no floppy emulation, no network,
> etc.), but the firmware already shows up the debug monitor prompt in the
> framebuffer display, so at least the very basics are already working.
>
> This code has been taken from Bryce
On Sun, Aug 04, 2019 at 07:04:12PM +0200, Kővágó, Zoltán wrote:
> Hello,
>
> This is the v3 of my audio patches. audiodev argument of wavcapture hmp
> is now mandatory.
Looks good, survived basic testing, queuing up for 4.2
thanks,
Gerd
On 7/9/19 9:32 AM, Thomas Huth wrote:
> From: Laurent Vivier
>
> On Sparc and PowerMac, the bit 0 of the address selects the register
> type (control or data) and bit 1 selects the channel (B or A).
>
> On m68k Macintosh and NeXTcube, the bit 0 selects the channel and
> bit 1 the register type.
On 7/9/19 9:32 AM, Thomas Huth wrote:
> The NeXTcube uses a normal 8530 serial controller, so we can simply use
> our normal "escc" device here.
> While we're at it, also add a boot-serial-test for the next-cube machine,
> now that the serial output works.
>
> Signed-off-by: Thomas Huth
Tested-b
From: "Dr. David Alan Gilbert"
This fixes a symptom I've seen on vhost-user on aarch64 where the
daemon would be falsely notified of memory region changes that didn't
exist.
The underlying problem was me memcmp'ing MemoryRegionSections even
though they had padding in.
(Discovered while getting v
From: "Dr. David Alan Gilbert"
Using memcmp to compare structures wasn't safe,
as I found out on ARM when I was getting false miscompares.
Use the helper function for comparing the MRSs.
Fixes: ade6d081fc33948e56e6
Signed-off-by: Dr. David Alan Gilbert
---
hw/virtio/vhost.c | 9 +++--
1
From: "Dr. David Alan Gilbert"
MemoryRegionSection includes an Int128 'size' field;
on some platforms the compiler causes an alignment of this to
a 128bit boundary, leaving 8 bytes of dead space.
This deadspace can be filled with junk.
Move the size field to the top avoiding unnecsssary alignmen
Hi Prasad,
On 8/13/19 12:05 PM, P J P wrote:
> +-- On Fri, 9 Aug 2019, P J P wrote --+
> | From: Prasad J Pandit
> |
> | When executing script in lsi_execute_script(), the LSI scsi
> | adapter emulator advances 's->dsp' index to read next opcode.
> | This can lead to an infinite loop if the next
Am 12.08.2019 um 17:56 hat Max Reitz geschrieben:
> On 12.08.19 17:33, Vladimir Sementsov-Ogievskiy wrote:
> > 25.07.2019 18:55, Max Reitz wrote:
> >> vpc is not really a passthrough driver, even when using the fixed
> >> subformat (where host and guest offsets are equal). It should handle
> >> pr
Markus Armbruster writes:
> Markus Armbruster writes:
>
>> Alex Bennée writes:
>>
>>> Markus Armbruster writes:
>>>
While there, drop the obsolete file comment.
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
On Mon, Aug 12, 2019 at 5:23 PM Kevin Wolf wrote:
> Am 11.08.2019 um 22:50 hat Nir Soffer geschrieben:
> > In some cases buf_align or request_alignment cannot be detected:
> >
> > - With Gluster, buf_align cannot be detected since the actual I/O is
> > done on Gluster server, and qemu buffer al
Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
> BDRV_BLOCK_RAW makes generic bdrv_co_block_status to fallthrough to
> returned file. But is it correct behavior at all? If returned file
> itself has a backing file, we may report as totally unallocated and
> area which actually
13.08.2019 12:33, Vladimir Sementsov-Ogievskiy wrote:
> 13.08.2019 12:01, Vladimir Sementsov-Ogievskiy wrote:
>> 13.08.2019 11:39, Vladimir Sementsov-Ogievskiy wrote:
>>> 12.08.2019 22:50, Max Reitz wrote:
On 12.08.19 21:46, Max Reitz wrote:
> On 12.08.19 20:11, Vladimir Sementsov-Ogievski
Alex Bennée writes:
> Markus Armbruster writes:
>
>> Markus Armbruster writes:
>>
>>> Alex Bennée writes:
>>>
Markus Armbruster writes:
> While there, drop the obsolete file comment.
>
> Signed-off-by: Markus Armbruster
> Reviewed-by: Philippe Mathieu-Daudé
> T
From: Kővágó, Zoltán
There's already a MIN and MAX macro in include/qemu/osdep.h, use them
instead.
Signed-off-by: Kővágó, Zoltán
Reviewed-by: Marc-André Lureau
Message-id:
7b8f396f8d2048f5ac26da52b77e5d48249c7645.1564925486.git.dirty.ice...@gmail.com
Signed-off-by: Gerd Hoffmann
---
audio/
From: Kővágó, Zoltán
Signed-off-by: Kővágó, Zoltán
Acked-by: Dr. David Alan Gilbert
Message-id:
ff28a2d4a61be1e7150556342a5fb83aa818c439.1564925486.git.dirty.ice...@gmail.com
Signed-off-by: Gerd Hoffmann
---
ui/vnc.h| 2 ++
monitor/misc.c | 22 +++---
ui/vnc.c
From: Kővágó, Zoltán
Finally add audiodev= options to audio frontends so users can specify
which backend to use when multiple backends exist. Not specifying an
audiodev= option currently causes the first audiodev to be used, this is
fixed in the next commit.
Example usage: -audiodev pa,id=foo -
From: Kővágó, Zoltán
Audio functions no longer access glob_audio_state, instead they get an
AudioState as a parameter. This is required in order to support
multiple backends.
glob_audio_state is also gone, and replaced with a tailq so we can store
more than one states.
Signed-off-by: Kővágó, Z
The following changes since commit 5e7bcdcfe69ce0fad66012b2cfb2035003c37eef:
display/bochs: fix pcie support (2019-08-12 16:36:41 +0100)
are available in the Git repository at:
git://git.kraxel.org/qemu tags/audio-20190813-pull-request
for you to fetch changes up to
From: Kővágó, Zoltán
Unless we disable stream moving, pulseaudio can easily move the stream
on connect, effectively ignoring the source/sink specified by the user.
Signed-off-by: Kővágó, Zoltán
Reviewed-by: Marc-André Lureau
Message-id:
274fc4ecc9125605a210b737c7fd927c51ff08ce.1564925486.git.
From: Kővágó, Zoltán
audio_run is called manually by alsa and oss backends when polling.
In this case only the requesting backend should be run, not all of them.
Signed-off-by: Kővágó, Zoltán
Reviewed-by: Marc-André Lureau
Message-id:
6bde77dcba080901bedf42beca3c9d71822fc261.1564925486.git.di
From: Kővágó, Zoltán
Remove glob_audio_state from functions, where possible without breaking
the API. This means that most static functions in audio.c now take an
AudioState pointer instead of implicitly using glob_audio_state. Also
included a pointer in SWVoice*, HWVoice* structs, so that func
From: Kővágó, Zoltán
This means you should probably stop using -soundhw (as it doesn't allow
you to specify any options) and add the device manually with -device.
The exception is pcspk, it's currently not possible to manually add it.
To use it with audiodev, use something like this:
-audiod
From: Kővágó, Zoltán
Signed-off-by: Kővágó, Zoltán
Message-id:
77ff4b0fa47bdf2766d2e0d5d3dafe759bd35a39.1564925486.git.dirty.ice...@gmail.com
Signed-off-by: Gerd Hoffmann
---
audio/audio.h | 4 +-
audio/audio_int.h | 26 +++
audio/audio_template.h | 14 ++--
audio/mix
From: Kővágó, Zoltán
They just called audio_pcm_sw_read/write anyway, so it makes no sense
to have them too. (The noaudio's read is the only exception, but it
should work with the generic code too.)
Signed-off-by: Kővágó, Zoltán
Message-id:
07e99c2877870cb486a07881a77d3ce0bc594daa.1564925486.
Am 13.08.2019 um 12:45 hat Nir Soffer geschrieben:
> On Mon, Aug 12, 2019 at 5:23 PM Kevin Wolf wrote:
>
> > Am 11.08.2019 um 22:50 hat Nir Soffer geschrieben:
> > > In some cases buf_align or request_alignment cannot be detected:
> > >
> > > - With Gluster, buf_align cannot be detected since the
From: Stefan Weil
Signed-off-by: Stefan Weil
Reviewed-by: Marc-André Lureau
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Message-id: 20190718193441.12490-1...@weilnetz.de
Signed-off-by: Gerd Hoffmann
---
audio/audio.c | 2 ++
1 file changed, 2 insertions(+)
diff --
From: Kővágó, Zoltán
Signed-off-by: Kővágó, Zoltán
Message-id:
752d0beb8a35abc89cbe0618a21e496c072a317e.1564925487.git.dirty.ice...@gmail.com
Signed-off-by: Gerd Hoffmann
---
audio/audio.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/audio/audio.c b/audio/audio.c
index d3c639211d
On Tue, 13 Aug 2019 at 12:20, Gerd Hoffmann wrote:
>
> The following changes since commit 5e7bcdcfe69ce0fad66012b2cfb2035003c37eef:
>
> display/bochs: fix pcie support (2019-08-12 16:36:41 +0100)
>
> are available in the Git repository at:
>
> git://git.kraxel.org/
From: Kővágó, Zoltán
Pulseaudio normally assumes that when the server wants it, the client
can generate the audio samples and send it right away. Unfortunately
this is not the case with QEMU -- it's up to the emulated system when
does it generate the samples. Buffering the samples and sending t
From: Kővágó, Zoltán
Currently this needs a workaround due to bug #247 in pulseaudio.
Signed-off-by: Kővágó, Zoltán
Reviewed-by: Marc-André Lureau
Message-id:
d1085ec6129416705b2cb65737e510ec9ffec508.1564925486.git.dirty.ice...@gmail.com
Signed-off-by: Gerd Hoffmann
---
audio/paaudio.c | 25
From: Kővágó, Zoltán
Have a pool of refcounted connections per server, so if the user creates
multiple audiodevs to the same pa server, it will use a single connection. (It
will still create different streams, so the user can manage those streams
separately in pulseaudio.)
Signed-off-by: Kővágó
13.08.2019 14:04, Kevin Wolf wrote:
> Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> BDRV_BLOCK_RAW makes generic bdrv_co_block_status to fallthrough to
>> returned file. But is it correct behavior at all? If returned file
>> itself has a backing file, we may report as tota
On Tue, Aug 06, 2019 at 06:23:38AM -0700, Guenter Roeck wrote:
> On 8/2/19 7:11 AM, Gerd Hoffmann wrote:
> > On Wed, Jul 31, 2019 at 01:08:50PM +0200, Philippe Mathieu-Daudé wrote:
> > > On 7/30/19 7:45 PM, Guenter Roeck wrote:
> > > > The following assert is seen once in a while while resetting th
> >
> > are available in the Git repository at:
> >
> > git://github.com/dgibson/qemu.git tags/ppc-for-4.1-20190813
> >
> > for you to fetch changes up to 310cda5b5e9df642b19a0e9c504368ffba3b3ab9:
> >
>
Am 13.08.2019 um 13:14 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 13.08.2019 12:33, Vladimir Sementsov-Ogievskiy wrote:
> > 13.08.2019 12:01, Vladimir Sementsov-Ogievskiy wrote:
> >> 13.08.2019 11:39, Vladimir Sementsov-Ogievskiy wrote:
> >>> 12.08.2019 22:50, Max Reitz wrote:
> On 12.08.
0)
> >
> > are available in the Git repository at:
> >
> > git://git.kraxel.org/qemu tags/audio-20190813-pull-request
> >
> > for you to fetch changes up to 7f6f83e89de6967db66a87f7ceb7be3c02a24d56:
> >
>
Am 13.08.2019 um 13:28 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 13.08.2019 14:04, Kevin Wolf wrote:
> > Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >> BDRV_BLOCK_RAW makes generic bdrv_co_block_status to fallthrough to
> >> returned file. But is it correct behavior
PINGING...
On 30/07/2019 19:01, Andrey Shinkevich wrote:
> Running unit tests under the Valgrind may help to detect QEMU memory issues
> (suggested by Denis V. Lunev). Some of the Valgrind reports relate to the
> unit test code itself. Let's eliminate the detected memory issues to ease
> locating
PINGING...
On 30/07/2019 13:13, Andrey Shinkevich wrote:
> Not all the paths in the functions, such as f16ToFloatX(), initialize
> the member 'exp' of the structure floatX.
>
> Signed-off-by: Andrey Shinkevich
> ---
> source/slowfloat.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --
>> display/bochs: fix pcie support (2019-08-12 16:36:41 +0100)
>>>
>>> are available in the Git repository at:
>>>
>>> git://github.com/dgibson/qemu.git tags/ppc-for-4.1-20190813
>>>
>>> for you to fetch changes up to 310cda5b5e9df
On 13/08/19 14:02, Andrey Shinkevich wrote:
> PINGING...
I thought I had already said I queued the series?
Paolo
> On 30/07/2019 19:01, Andrey Shinkevich wrote:
>> Running unit tests under the Valgrind may help to detect QEMU memory issues
>> (suggested by Denis V. Lunev). Some of the Valgrind r
On 13/08/19 12:29, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> This fixes a symptom I've seen on vhost-user on aarch64 where the
> daemon would be falsely notified of memory region changes that didn't
> exist.
> The underlying problem was me memcmp'ing MemoryRegionSec
On 13/08/2019 15:05, Paolo Bonzini wrote:
> On 13/08/19 14:02, Andrey Shinkevich wrote:
>> PINGING...
>
> I thought I had already said I queued the series?
>
> Paolo
>
Thank you Paolo.
I am clear now.
Andrey
>> On 30/07/2019 19:01, Andrey Shinkevich wrote:
>>> Running unit tests under the V
On Tue 30 Jul 2019 06:01:36 PM CEST, Andrey Shinkevich wrote:
> ThrottleState::cfg of the static variable 'ts' is reassigned with the
> local one in the do_test_accounting() and then is passed to the
> throttle_account() with uninitialized member LeakyBucket::burst_length.
>
> Signed-off-by: Andrey
Andrey Shinkevich writes:
> PINGING...
Sorry about the delay. I did attempt see if the existing code threw up
any errors when built with clang's undefined sanitizer. I think this is
because xPtr->exp will only get read if none of the xPtr->isFOO returns
false. In all those cases xPtr->exp is s
We have a wrapper that does the right thing from stdint.h so lets use
it for our constants in softfloat-specialize.h
Signed-off-by: Alex Bennée
---
fpu/softfloat-specialize.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/fpu/softfloat-specialize
Using the floatXX_pack_raw functions is slight overkill for basically
just masking out all but the top bit of the number. This makes the
final code exactly the same as pre-conversion.
TODO: is this worth it, can the compiler do better with make_float?
Signed-off-by: Alex Bennée
---
fpu/softfloa
Hi,
Another iteration of updates for softfloat. Instead of moving the
LIT64() macro from one file to another we convert the uses to the
stdint.h macro. I did eliminate one of the uses by converting the
squash_input_denormal functions to the new style code. However as you
can see with the follow-up
This also allows us to remove the extractFloat16exp/frac helpers.
Signed-off-by: Alex Bennée
---
fpu/softfloat.c | 110 +---
1 file changed, 47 insertions(+), 63 deletions(-)
diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 2ba36ec3703..0a434555cd
This is not a normal header and should only be included in the main
softfloat.c file to bring in the various target specific
specialisations. Indeed as it contains non-inlined C functions it is
not even a legal header. Rename it to match our included C convention.
Signed-off-by: Alex Bennée
Revie
Now the rest of the code has been cleaned up we can remove this.
Signed-off-by: Alex Bennée
---
include/fpu/softfloat.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/fpu/softfloat.h b/include/fpu/softfloat.h
index 3ff3fa52245..d9333eb65b8 100644
--- a/include/fpu/softfloat.h
+++ b
Remove some more use of LIT64 while making the meaning more clear. We
also avoid the need of casts as the results by definition fit into the
return type.
Signed-off-by: Alex Bennée
---
fpu/softfloat.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --
The macros use the "flags" type and to be consistent if anyone just
needs the macros we should bring in the header we need. There is an
outstanding TODO to audit the use of "flags" and replace with bool at
which point this include could be dropped.
Signed-off-by: Alex Bennée
Acked-by: Richard Hen
There are a bunch of users of the inline helpers who do not need
access to the entire softfloat API. Move those inline helpers into a
new header file which can be included without bringing in the rest of
the world.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Reviewed-by: Philippe M
In our quest to eliminate the home rolled LIT64 macro we fixup usage
inside for m68k's many constants.
Signed-off-by: Alex Bennée
---
target/m68k/softfloat.c | 98 -
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/target/m68k/softfloat.c b/
In our quest to eliminate the home rolled LIT64 macro we fixup usage
inside the softfloat code. While we are at it we remove some of the
extraneous spaces to closer fit the house style.
Signed-off-by: Alex Bennée
---
fpu/softfloat.c| 118 -
include
We should avoid including the whole of softfloat headers in cpu.h and
explicitly include it only where we will be calling softfloat
functions. We can use the -types.h in cpu.h for the few bits that are
global. We also move the restore_snan_bit_mode into internal.h and
include -helpers.h there.
Sig
On 13.08.19 14:52, Cornelia Huck wrote:
> On Mon, 12 Aug 2019 15:37:39 +0200
> David Hildenbrand wrote:
>
>> On 12.08.19 13:27, David Hildenbrand wrote:
>>> Instructions are always fetched from primary address space, except when
>>> in home address mode. Perform the selection directly in cpu_mmu_
On Mon, 12 Aug 2019 13:27:32 +0200
David Hildenbrand wrote:
> Let's select the ASC before calling the function. This is a prepararion
> to remove the ASC magic depending on the access mode from mmu_translate.
>
> There is currently no way to distinguish if we have code or data access.
> For now,
Generally the cpu and non-FP helper files just want to manipulate the
softfloat flags. For this they can just use the -helpers.h include
which brings in a minimal number of inline helpers.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Reviewed-by: David Hildenbrand
---
target/alpha
1 - 100 of 294 matches
Mail list logo
