On 7/22/20 5:50 AM, Thiago Jung Bauermann wrote:
> Instead of setting CPUState::halted to 1 in ppce500_cpu_reset_sec(), use
> the start-powered-off property which makes cpu_common_reset() initialize it
> to 1 in common code.
>
> Signed-off-by: Thiago Jung Bauermann
> ---
> hw/ppc/e500.c | 10 +++
On 7/22/20 5:50 AM, Thiago Jung Bauermann wrote:
> This change is in a separate patch because it's not so obvious that it
> won't cause a regression.
>
> Suggested-by: Eduardo Habkost
> Signed-off-by: Thiago Jung Bauermann
> ---
> hw/core/cpu.c| 2 +-
> target/arm/cpu.c | 1 -
> 2 files cha
Hi Thiago,
On 7/22/20 5:50 AM, Thiago Jung Bauermann wrote:
> There are other platforms which also have CPUs that start powered off, so
> generalize the start-powered-off property so that it can be used by them.
>
> Note that ARMv7MState also has a property of the same name but this patch
> doesn
Le 22/07/2020 à 08:29, Alex Bennée a écrit :
> From: Laurent Vivier
>
> If clock_nanosleep() encounters an error, it returns one of the positive
> error number.
>
> If the call is interrupted by a signal handler, it fails with error EINTR
> and if "remain" is not NULL and "flags" is not TIMER_AB
On 15.07.20 11:40, Janosch Frank wrote:
> The two main types of zipl component entries are execute and
> load/data. The last member of the component entry struct therefore
> denotes either a PSW or an address. Let's make this a bit more clear
> by introducing a union and cleaning up the code tha
On 7/22/20 8:28 AM, Alex Bennée wrote:
> It seems GetPhysicallyInstalledSystemMemory isn't available in the
> MinGW headers so we have to declare it ourselves. Compile tested only.
>
> Cc: Stefan Weil
> Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
> ---
> util/oslib-win32.c
On 21.07.20 09:05, Thomas Huth wrote:
> On 15/07/2020 11.40, Janosch Frank wrote:
[..]
>> #ifndef S390_ARCH_H
>> #define S390_ARCH_H
>>
>> +/* s390 psw bit masks */
>> +#define PSW_MASK_EXT0x0100UL
>> +#define PSW_MASK_IOINT 0x0200ULL
>> +#define PSW_MASK
On 7/22/20 8:28 AM, Alex Bennée wrote:
> From: Laszlo Ersek
>
> Quoting ISO C99 6.7.8p4, "All the expressions in an initializer for an
> object that has static storage duration shall be constant expressions or
> string literals".
>
> The compound literal produced by the make_floatx80() macro is
21.07.2020 15:29, Philippe Mathieu-Daudé wrote:
> On 7/20/20 9:45 PM, Michael Tokarev wrote:
...
>> For now we don't have any released qemu version with this situation
>> so not many project enabled workarounds for broken qemu behavour
>> like the xen-devel link above.
Note: all of the entries bel
On 15.07.20 16:08, Janosch Frank wrote:
> Normally they don't need to be set up before waiting for an interrupt
> but are set up on boot. The BIOS however might overwrite the lowcore
> (and hence the PSWs) when loading a blob into memory and therefore
> needs to set up those PSWs more often.
No
On 7/22/20 8:29 AM, Alex Bennée wrote:
> When we updated the arguments for docker.py we missed a bit.
>
Oops.
> Fixes: dfae6284
Fixes: dfae628459 ("docker.py/build: support -t and -f arguments")
(see https://www.mail-archive.com/qemu-devel@nongnu.org/msg711059.html)
Reviewed-by: Philippe Mathi
From: Laurent Vivier
If clock_nanosleep() encounters an error, it returns one of the positive
error number.
If the call is interrupted by a signal handler, it fails with error EINTR
and if "remain" is not NULL and "flags" is not TIMER_ABSTIME, it returns
the remaining unslept time in "remain".
When we updated the arguments for docker.py we missed a bit.
Fixes: dfae6284
Signed-off-by: Alex Bennée
---
tests/docker/Makefile.include | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index a104e9df281..9119dff97
From: Laszlo Ersek
Quoting ISO C99 6.7.8p4, "All the expressions in an initializer for an
object that has static storage duration shall be constant expressions or
string literals".
The compound literal produced by the make_floatx80() macro is not such a
constant expression, per 6.6p7-9. (An impl
Does this seem convoluted to you? It feels a little complicated to me.
Signed-off-by: Alex Bennée
---
tests/docker/docker.py | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/tests/docker/docker.py b/tests/docker/docker.py
index c9f20d8d093..356d7618f1a 100755
---
It seems GetPhysicallyInstalledSystemMemory isn't available in the
MinGW headers so we have to declare it ourselves. Compile tested only.
Cc: Stefan Weil
Signed-off-by: Alex Bennée
---
util/oslib-win32.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/util/o
It turns out there are some 64 bit systems that have relatively low
amounts of physical memory available to them (typically CI system).
Even with swapping available a 1GB translation buffer that fills up
can put the machine under increased memory pressure. Detect these low
memory situations and red
For installing stuff from sid or ports you may need to manually
specify the location of the keyring. You can even import keys into
your personal keyring and point it there, e.g.:
gpg --keyserver keyring.debian.org --recv-keys 84C573CD4E1AFD6C
make docker-binfmt-image-debian-sid-hppa DEB_TYPE=s
From: KONRAD Frederic
With that we can just use -semihosting-config chardev=serial0.
[AJB: tweak commit message]
Signed-off-by: KONRAD Frederic
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Message-Id: <1592215252-26742-1-git-send-email-frederic.kon...@adacore.com>
Message-Id: <2
Plain MAP_FIXED has the undesirable behaviour of splatting exiting
maps so we don't actually achieve what we want when looking for gaps.
We should be using MAP_FIXED_NOREPLACE. As this isn't always available
we need to potentially check the returned address to see if the kernel
gave us what we aske
The registry url is //qemu/
Perhaps we should rationalise that some day but for now.
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20200717105139.25293-2-alex.ben...@linaro.org>
---
.shippable.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Hi,
This is the current state of my candidate fixes for 5.1. Apart from
the revisions following reviews I was only going to add one more fix
(the pgd fallback code not using MAP_FIXED). But as is the usual way
of things I found a few bits and pieces on the way.
I haven't been able to replicate th
From: KONRAD Frederic
Don't send the trailing 0 from the string.
Signed-off-by: KONRAD Frederic
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-Id: <1592215252-26742-2-git-send-email-frederic.kon...@adacore.com>
Message-Id: <2020071710513
This will be used in a future patch. For POSIX systems _SC_PHYS_PAGES
isn't standardised but at least appears in the man pages for
Open/FreeBSD. The result is advisory so any users of it shouldn't just
fail if we can't work it out.
The win32 stub currently returns 0 until someone with a Windows sy
Having spent a while searching for answers on this I am making a last-ditch
effort by contacting the devel group.
Could someone let me know if it is possible to change the default disk
cache setting in qemu globally?
Currently it is set to writeback, in many if not most use cases "none" is
optima
Peter Maydell writes:
> On Tue, 21 Jul 2020 at 17:07, Philippe Mathieu-Daudé
> wrote:
>>
>> Hi Stefan,
>>
>> I'm trying to understand what is modelling the
>> TYPE_TPM_TIS_ISA device.
>>
>> It inherits from TYPE_ISA_DEVICE, so I expected
>> to see an ISA device, but then I noticed:
>>
>> 1/ it
On 2020/7/22 下午12:47, Li Qiang wrote:
Jason Wang 于2020年7月22日周三 上午11:32写道：
On 2020/7/21 下午11:17, Li Qiang wrote:
Alexander Bulekov reported a UAF bug related e1000e packets send.
-->https://bugs.launchpad.net/qemu/+bug/1886362
This is because the guest trigger a e1000e packet send and set
Hi Zong,
On Tue, Jul 21, 2020 at 8:41 PM Zong Li wrote:
>
> On RV64, the reg_index is 2 (pmpcfg2 CSR) after the seventh pmp
> entry, it is not 1 (pmpcfg1 CSR) like RV32. In the original
> implementation, the second parameter of pmp_write_cfg is
> "reg_index * sizeof(target_ulong)", and we get the
+-- On Wed, 22 Jul 2020, Jason Wang wrote --+
| On 2020/7/21 下午11:17, Li Qiang wrote:
| > Alexander Bulekov reported a UAF bug related e1000e packets send.
| >
| > -->https://bugs.launchpad.net/qemu/+bug/1886362
| >
| > This is because the guest trigger a e1000e packet send and set the
| > data's a
This has been fixed here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1019242af11400252
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/175149
Jason Wang 于2020年7月22日周三 上午11:32写道：
>
>
> On 2020/7/21 下午11:17, Li Qiang wrote:
> > Alexander Bulekov reported a UAF bug related e1000e packets send.
> >
> > -->https://bugs.launchpad.net/qemu/+bug/1886362
> >
> > This is because the guest trigger a e1000e packet send and set the
> > data's addres
The libudev-related code is independent from the other pci-related code
and can be re-used for non-pci devices (like ccw devices on s390x). Thus
move this part to the generic function.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1755075
Signed-off-by: Thomas Huth
---
qga/commands-posix.
We are going to support non-PCI devices soon. For this we need to split
the generic GuestDiskAddress and GuestDiskAddressList memory allocation
and list chaining into a separate function first.
Signed-off-by: Thomas Huth
---
qga/commands-posix.c | 65
QEMU on s390x uses virtio via channel I/O instead of PCI by default.
Add a function to detect and provide information for virtio-scsi and
virtio-block devices here, too.
Signed-off-by: Thomas Huth
---
qga/commands-posix.c | 42 +-
1 file changed, 41 insert
The "guest-get-fsinfo" could also be used for non-PCI devices in the
future. And the code in GuestPCIAddress() in qga/commands-win32.c seems
to be using "-1" for fields that it can not determine already. Thus
let's properly document "-1" as value for invalid PCI address fields.
Reviewed-by: Daniel
The information that can be retrieved via UDEV is also usable for non-PCI
devices. So let's allow build_guest_fsinfo_for_real_device() on non-PCI
devices, too. This is required to fix the bug that CCW devices show up
without "Target" when running libvirt's "virsh domfsinfo" command (see
https://bug
I'm sorry, but the QEMU project only supports the two most recent
versions of macOS (see https://www.qemu.org/docs/master/system/build-
platforms.html#macos ), i.e. everything that is older than macOS 10.14
is not supported anymore.
** Changed in: qemu
Status: New => Won't Fix
--
You rece
On 7/4/20 12:14 PM, Launchpad Bug Tracker wrote:
You have been subscribed to a public bug by Philippe Mathieu-Daudé (philmd):
Hello,
While fuzzing, I found an input that triggers a null-ptr dereference in
address_space_to_flatview through ide:
==31699==ERROR: AddressSanitizer: SEGV on unknown a
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1693667
Title:
-cpu haswel
On 7/17/20 3:53 AM, Philippe Mathieu-Daudé wrote:
libFuzzer found a case where requests are queued for later in the
AIO context, but a command set the bus inactive, then when finally
the requests are processed by the DMA it aborts because it is
inactive:
include/hw/ide/pci.h:59: IDEState *bmdm
Instead of setting CPUState::halted to 1 in s390_cpu_initfn(), use the
start-powered-off property which makes cpu_common_reset() initialize it to
1 in common code.
Signed-off-by: Thiago Jung Bauermann
---
target/s390x/cpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
NB: I was only
Remove setting of cs->halted from cpu_devinit(), which seems out of place
when compared to similar code in other architectures (e.g., ppce500_init()
in hw/ppc/e500.c).
Signed-off-by: Thiago Jung Bauermann
---
hw/sparc/sun4m.c | 1 -
1 file changed, 1 deletion(-)
NB: I was only able to test that
Instead of setting CPUState::halted to 1 in ppce500_cpu_reset_sec(), use
the start-powered-off property which makes cpu_common_reset() initialize it
to 1 in common code.
Signed-off-by: Thiago Jung Bauermann
---
hw/ppc/e500.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
NB: I
If we rely on cpu_common_reset() setting CPUState::halted according to the
start-powered-off property, both reset functions become equivalent and we
can use only one.
Signed-off-by: Thiago Jung Bauermann
---
hw/sparc/sun4m.c | 21 -
1 file changed, 4 insertions(+), 17 deletio
Instead of setting CPUState::halted to 1 in main_cpu_reset(), use the
start-powered-off property which makes cpu_common_reset() initialize it
to 1 in common code.
Signed-off-by: Thiago Jung Bauermann
---
hw/mips/cps.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
NB: I was only ab
Instead of setting CPUState::halted to 1 in secondary_cpu_reset(), use the
start-powered-off property which makes cpu_common_reset() initialize it
to 1 in common code.
Signed-off-by: Thiago Jung Bauermann
---
hw/sparc/sun4m.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
NB: I was onl
PowerPC sPAPR CPUs start in the halted state, and spapr_reset_vcpu()
attempts to implement this by setting CPUState::halted to 1. But that's too
late for the case of hotplugged CPUs in a machine configure with 2 or more
threads per core.
By then, other parts of QEMU have already caused the vCPU to
There are other platforms which also have CPUs that start powered off, so
generalize the start-powered-off property so that it can be used by them.
Note that ARMv7MState also has a property of the same name but this patch
doesn't change it because that class isn't a subclass of CPUState so it
woul
This change is in a separate patch because it's not so obvious that it
won't cause a regression.
Suggested-by: Eduardo Habkost
Signed-off-by: Thiago Jung Bauermann
---
hw/core/cpu.c| 2 +-
target/arm/cpu.c | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
NB: I was only able to test t
The ARM code has a start-powered-off property in ARMCPU, which is a
subclass of CPUState. This property causes arm_cpu_reset() to set
CPUState::halted to 1, signalling that the CPU should start in a halted
state. Other architectures also have code which aim to achieve the same
effect, but without u
On 2020/7/21 19:54, Daniel P. Berrangé wrote:
> On Fri, Jul 17, 2020 at 05:19:43PM +0800, Zhenyu Ye wrote:
>> We add the reference of creds in migration_tls_get_creds(),
>> but there was no place to unref it. So the OBJECT(creds) will
>> never be freed and result in memory leak.
>>
>> Unref the cr
On 2020/7/21 下午11:56, Peter Maydell wrote:
It is not helpful if everybody sends their pullrequests late
on the Tuesday afternoon, as there just isn't enough time in the
day to merge test and apply them all before I have to cut the tag.
Please, if you can, try to send pullrequests earlier, eg Mo
Currently migration_tls_get_creds() adds the reference of creds
but there was no place to unref it. So the OBJECT(creds) will
never be freed and result in memory leak.
The leak stack:
Direct leak of 104 byte(s) in 1 object(s) allocated from:
#0 0xa88bd20b in __interceptor_malloc (/usr/lib
On 2020/7/21 下午11:17, Li Qiang wrote:
Alexander Bulekov reported a UAF bug related e1000e packets send.
-->https://bugs.launchpad.net/qemu/+bug/1886362
This is because the guest trigger a e1000e packet send and set the
data's address to e1000e's MMIO address. So when the e1000e do DMA
it will
On 2020/7/21 下午9:46, Li Qiang wrote:
Jason Wang 于2020年7月21日周二 下午9:21写道：
On 2020/7/21 下午8:31, Peter Maydell wrote:
On Wed, 15 Jul 2020 at 09:36, Jason Wang wrote:
I think the point is to make DMA to MMIO work as real hardware.
I wouldn't care to give a 100% guarantee that asking a real
h/
On 2020/7/21 下午9:44, Peter Maydell wrote:
On Tue, 21 Jul 2020 at 14:21, Jason Wang wrote:
On 2020/7/21 下午8:31, Peter Maydell wrote:
On Wed, 15 Jul 2020 at 09:36, Jason Wang wrote:
I think the point is to make DMA to MMIO work as real hardware.
I wouldn't care to give a 100% guarantee that
> From: Xiang Zheng
> Sent: Wednesday, July 22, 2020 10:56 AM
>
> Hi Alex,
>
> Thank you for your suggestion.
>
> On 2020/7/22 6:43, Alex Williamson wrote:
> > On Tue, 21 Jul 2020 10:43:21 +0800
> > Xiang Zheng wrote:
> >
> >> Hi Kirti,
> >>
> >> Sorry to disturb you since this patch set has be
Hi Alex,
Thank you for your suggestion.
On 2020/7/22 6:43, Alex Williamson wrote:
> On Tue, 21 Jul 2020 10:43:21 +0800
> Xiang Zheng wrote:
>
>> Hi Kirti,
>>
>> Sorry to disturb you since this patch set has been merged, and I cannot
>> receive the qemu-side emails about this patch set.
>>
>> We
Ping.
On 2020/7/12 0:16, LIU Zhiwei wrote:
In contrast to the RFC, add more instructions description. Now it supports
RV64IMACFD. Some cross verifications have been done, such as comparison
between QEMU and TinyEMU, and comparison between QEMU and C906 FPGA.
Now it has some productive.
Feature
Hello,
On behalf of the QEMU Team, I'd like to announce the availability of the
second release candidate for the QEMU 5.1 release. This release is meant
for testing purposes and should not be used in a production environment.
http://download.qemu-project.org/qemu-5.1.0-rc1.tar.xz
http://down
Python script that locates the commit that caused a performance
degradation or improvement in QEMU using the git bisect command
(binary search).
Syntax:
bisect.py [-h] -s,--start START [-e,--end END] [-q,--qemu QEMU] \
--target TARGET --tool {perf,callgrind} -- \
[]
[-h] - Print the script argum
Hi,
This series adds the new bisect.py script introduced in report 5 of
the "TCG Continuous Benchmarking" GSoC project.
The script is used for locating the commit that caused a performance
degradation or improvement in QEMU using the git bisect command
(binary search).
To learn more about how th
On Tue, 21 Jul 2020 10:43:21 +0800
Xiang Zheng wrote:
> Hi Kirti,
>
> Sorry to disturb you since this patch set has been merged, and I cannot
> receive the qemu-side emails about this patch set.
>
> We are going to support migration for VFIO devices which support dirty
> pages tracking.
>
> An
On Tue, Jul 21, 2020 at 1:54 PM Alex Bennée wrote:
>
>
> Ahmed Karaman writes:
>
> > Hi,
> >
> > The fifth report of the TCG Continuous Benchmarking project concludes
> > a mini-series of three reports that dealt with the performance
> > comparison and analysis of QEMU 5.0 and 5.1-pre-soft-freeze
On 7/15/20 1:06 AM, Klaus Jensen wrote:
> Hi Andrzej,
>
> I've not been ignoring this, but sorry for not following up earlier.
>
> I'm hesitent to merge anything that very obviously breaks an OS that we
> know is used a lot to this using this device. Also because the issue has
> not been analyzed
On Tue, Jul 21, 2020 at 04:56:25PM +0100, Peter Maydell wrote:
> It is not helpful if everybody sends their pullrequests late
> on the Tuesday afternoon, as there just isn't enough time in the
> day to merge test and apply them all before I have to cut the tag.
> Please, if you can, try to send pul
Public bug reported:
Hi all,
build of tag v5.1.0-rc1 fails on Mac OS X 10.11.6 (El Capitan) with the
following error:
git clone https://git.qemu.org/git/qemu.git
cd qemu
git submodule init
git submodule update --recursive
./configure
make
CC trace/control.o
In fi
On Tue, Jul 21, 2020 at 12:50 PM Alex Bennée wrote:
>
>
> Lirong Yuan writes:
>
> > On Tue, Mar 31, 2020 at 12:20 AM Alex Bennée wrote:
> >>
> >>
> >> Lirong Yuan writes:
> >>
> >> > On Mon, Mar 30, 2020 at 12:47 PM Alex Bennée
> >> > wrote:
> >> >
> >> >>
> >> >> Lirong Yuan writes:
> >> >>
Laurent Vivier writes:
> If clock_nanosleep() encounters an error, it returns one of the positive
> error number.
>
> If the call is interrupted by a signal handler, it fails with error EINTR
> and if "remain" is not NULL and "flags" is not TIMER_ABSTIME, it returns
> the remaining unslept time
If clock_nanosleep() encounters an error, it returns one of the positive
error number.
If the call is interrupted by a signal handler, it fails with error EINTR
and if "remain" is not NULL and "flags" is not TIMER_ABSTIME, it returns
the remaining unslept time in "remain".
Update linux-user to no
Status from old attempts to solve same nature issues:
Older (2018) merge request from @raharper:
https://github.com/koverstreet/bcache-tools/pull/1
addressing the fact that kernel uevents would not always emit
CACHED_UUID parameters, making udev to delete (whenever that happens)
/dev/bca
I've hidden last post as it was posted in the wrong bug.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
qemu-img hangs on rcu_call_ready_event logic in Aarch64 when
converting image
On 7/21/20 10:36 AM, Cédric Le Goater wrote:
> Hello,
>
> On 2/6/20 7:32 PM, Guenter Roeck wrote:
>> When requesting JEDEC data using the JEDEC_READ command, the Linux kernel
>> always requests 6 bytes. The current implementation only returns three
>> bytes, and interprets the remaining three byte
Lirong Yuan writes:
> On Tue, Mar 31, 2020 at 12:20 AM Alex Bennée wrote:
>>
>>
>> Lirong Yuan writes:
>>
>> > On Mon, Mar 30, 2020 at 12:47 PM Alex Bennée
>> > wrote:
>> >
>> >>
>> >> Lirong Yuan writes:
>> >>
>> >> > On Sat, Mar 21, 2020 at 6:56 AM Alex Bennée
>> >> wrote:
>> >> >
>> >>
On Tue, 21 Jul 2020 at 16:25, Markus Armbruster wrote:
>
> The following changes since commit af3d69058e09bede9900f266a618ed11f76f49f3:
>
> Merge remote-tracking branch
> 'remotes/pmaydell/tags/pull-target-arm-20200720' into staging (2020-07-20
> 15:58:07 +0100)
>
> are available in the Git re
On Tue, 21 Jul 2020 at 16:46, Kevin Wolf wrote:
>
> The following changes since commit 90218a9a393c7925f330e7dcc08658e2a01d3bd4:
>
> Merge remote-tracking branch
> 'remotes/huth-gitlab/tags/pull-request-2020-07-21' into staging (2020-07-21
> 10:24:38 +0100)
>
> are available in the Git reposit
On 21.07.20 12:49, Alex Bennée wrote:
Stefan Hajnoczi writes:
Thank you everyone who joined!
I didn't take notes but two things stood out:
1. The ivshmem v2 and virtio-vhost-user use cases are quite different
so combining them does not seem realistic. ivshmem v2 needs to be as
simple for th
On 7/21/20 4:41 AM, David Hildenbrand wrote:
> [...]
>
+switch (code & SCLP_CMD_CODE_MASK) {
+default:
+if (sccb_max_addr < sccb_boundary) {
+return true;
+}
+}
>>>
>>> ^ what is that?
>>>
>>> if ((code & SCLP_CMD_CODE_MASK)
Your pipeline has failed.
Project: QEMU ( https://gitlab.com/qemu-project/qemu )
Branch: master ( https://gitlab.com/qemu-project/qemu/-/commits/master )
Commit: b50dab9e (
https://gitlab.com/qemu-project/qemu/-/commit/b50dab9ecac442acc1b316e4749dae36a2fe7d61
)
Commit Message: Merge remote-tr
On Tue, 21 Jul 2020 at 16:41, Markus Armbruster wrote:
>
> The following changes since commit af3d69058e09bede9900f266a618ed11f76f49f3:
>
> Merge remote-tracking branch
> 'remotes/pmaydell/tags/pull-target-arm-20200720' into staging (2020-07-20
> 15:58:07 +0100)
>
> are available in the Git re
The value returned by qemu_find_file() must be freed.
This fixes Coverity issue CID 1430449, which points out
that the memory returned by qemu_find_file() is leaked.
Fixes: Coverity CID 1430449 (RESOURCE_LEAK)
Fixes: 7dd8f6fde4 ('hw/avr: Add support for loading ELF/raw binaries')
Signed-off-by: P
This comment is confuse, reword it a bit.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Michael Rolnik
Tested-by: Michael Rolnik
Reviewed-by: Daniel P. Berrangé
Message-Id: <20200714164257.23330-3-f4...@amsat.org>
---
include/qemu/osdep.h | 5 -
1 file changed, 4 insertions(+), 1 del
Document os_find_datadir() returned data must be freed.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Michael Rolnik
Tested-by: Michael Rolnik
Reviewed-by: Daniel P. Berrangé
Message-Id: <20200714164257.23330-2-f4...@amsat.org>
---
os-posix.c | 3 +++
os-win32.c | 7 ++-
2 files chan
t tags/avr-20200721
for you to fetch changes up to 5e29521a82e540552880c3572cb8274bcaa1002c:
hw/avr/boot: Fix memory leak in avr_load_firmware() (2020-07-21 16:13:04 +0=
200)
AVR patches
Fixes a memory leak reported by Coverity (CID 143
Document qemu_find_file(), in particular the returned
value which must be freed.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Peter Maydell
Reviewed-by: Li Qiang
Reviewed-by: Michael Rolnik
Tested-by: Michael Rolnik
Reviewed-by: Daniel P. Berrangé
Message-Id: <20200714164257.23330-4-f4
On 7/18/20 3:28 AM, Philippe Mathieu-Daudé wrote:
libFuzzer triggered the following assertion:
cat << EOF | qemu-system-i386 -M pc-q35-5.0 \
-nographic -monitor none -serial none -qtest stdio
outl 0xcf8 0x8000fa24
outl 0xcfc 0xe1068000
outl 0xcf8 0x8000fa04
outw 0xcfc 0x7
Commits b6d7e9b66f..a43770df5d simplified the error propagation.
Similarly to commit 6fd5bef10b "qom: Make functions taking Error**
return bool, not void", let fw_cfg_add_from_generator() return a
boolean value, not void.
This allow to simplify parse_fw_cfg() and fixes the error handling
issue repo
Document FWCfgDataGeneratorClass::get_data() return NULL
on error, and non-NULL on success. This allow us to simplify
fw_cfg_add_from_generator(). Since we don't need a local
variable to propagate the error, we can remove the ERRP_GUARD()
macro.
Suggested-by: Markus Armbruster
Signed-off-by: Phil
ags/fw_cfg-20200721
for you to fetch changes up to 077195187b47d83418e5fb521c89d7881fab3049:
hw/nvram/fw_cfg: Let fw_cfg_add_from_generator() return boolean value (2020=
-07-21 16:47:54 +0200)
fw_cfg patches
Fixes the DEADCODE issue r
On Tue, Mar 31, 2020 at 12:20 AM Alex Bennée wrote:
>
>
> Lirong Yuan writes:
>
> > On Mon, Mar 30, 2020 at 12:47 PM Alex Bennée wrote:
> >
> >>
> >> Lirong Yuan writes:
> >>
> >> > On Sat, Mar 21, 2020 at 6:56 AM Alex Bennée
> >> wrote:
> >> >
> >> >>
> >> >> Lirong Yuan writes:
> >> >>
> >>
Public bug reported:
Current Arch linux release, up-to-date as of 7/21/2020.
Running a windows 7 virtual machine (also happens with windows 10,
possibly more OSes), with an nvidia GTX 1060 passthrough, if the VM is
attempted to be restarted, either through the guest interface, or by
libvirt's gui
On 7/18/20 3:28 AM, Philippe Mathieu-Daudé wrote:
libFuzzer triggered the following assertion:
cat << EOF | qemu-system-i386 -M pc-q35-5.0 \
-nographic -monitor none -serial none -qtest stdio
outl 0xcf8 0x8000fa24
outl 0xcfc 0xe1068000
outl 0xcf8 0x8000fa04
outw 0xcfc 0x7
Hello,
On 2/6/20 7:32 PM, Guenter Roeck wrote:
> When requesting JEDEC data using the JEDEC_READ command, the Linux kernel
> always requests 6 bytes. The current implementation only returns three
> bytes, and interprets the remaining three bytes as new commands.
> While this does not matter most o
On 7/18/20 9:28 AM, Philippe Mathieu-Daudé wrote:
> libFuzzer triggered the following assertion:
>
> cat << EOF | qemu-system-i386 -M pc-q35-5.0 \
> -nographic -monitor none -serial none -qtest stdio
> outl 0xcf8 0x8000fa24
> outl 0xcfc 0xe1068000
> outl 0xcf8 0x8000fa04
> outw 0xcfc
>
> are available in the Git repository at:
>
> git://git.kraxel.org/qemu tags/fixes-20200721-pull-request
>
> for you to fetch changes up to d87350b065128e8156e7aca93e89a1ab9e5fa63d:
>
> module: ignore NULL type (2020-07-21 10:56:51 +0200)
>
> ---
On 7/21/20 7:35 AM, Peter Maydell wrote:
> Commit 6a0b7505f1fd6769c which added documentation of the virt board
> crossed in the post with commit 6f4e1405b91da0d0 which added a new
> 'mte' machine option. Update the docs to include the new option.
>
> Signed-off-by: Peter Maydell
> ---
> docs/sy
On 21.07.20 18:35, Richard Henderson wrote:
When we changed the interface of get_phys_addr_lpae to require
the cacheattr parameter, this spot was missed. The compiler is
unable to detect the use of NULL vs the nonnull attribute here.
Fixes: 7e98e21c098
Reported-by: Jan Kiszka
Signed-off-by: Ri
On Tue, 21 Jul 2020 09:40:10 -0400
"Michael S. Tsirkin" wrote:
> On Fri, Jul 17, 2020 at 11:29:28AM +0200, Marc Hartmayer wrote:
> > Since virtio existed even before it got standardized, the virtio
> > standard defines the following types of virtio devices:
> >
> > + legacy device (pre-virtio 1
On Tue, 21 Jul 2020 at 17:07, Philippe Mathieu-Daudé wrote:
>
> Hi Stefan,
>
> I'm trying to understand what is modelling the
> TYPE_TPM_TIS_ISA device.
>
> It inherits from TYPE_ISA_DEVICE, so I expected
> to see an ISA device, but then I noticed:
>
> 1/ it doesn't use the ISA I/O space, it direc
On 7/21/20 12:02 PM, Philippe Mathieu-Daudé wrote:
Hi Stefan,
I'm trying to understand what is modelling the
TYPE_TPM_TIS_ISA device.
It inherits from TYPE_ISA_DEVICE, so I expected
to see an ISA device, but then I noticed:
1/ it doesn't use the ISA I/O space, it directly
maps the device in th
1 - 100 of 299 matches
Mail list logo
