[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/1649040
Title:
Ubuntu
[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/1665389
Title:
Nested kvm
[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/1663079
Title:
socket
As struct target_ucontext will be transfered to signal handler, it
must keep pace with struct ucontext_t defined in Linux kernel.
Signed-off-by: LIU Zhiwei
---
linux-user/riscv/signal.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/linux-user/riscv/signal.c
Hi,
I built against the latest library I could (Windows Insider Preview,
SDK) - same failure.
Thoughts?
Thanks!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1821595
Title:
Failed to emulate
Should say - I rebuilt (today). Still no joy.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1821595
Title:
Failed to emulate MMIO access with EmulatorReturnStatus: 2
Status in QEMU:
New
Bug
On Sat, Apr 11, 2020 at 11:57:23PM +1000, Nicholas Piggin wrote:
> Nicholas Piggin's on April 11, 2020 7:32 pm:
> > Nathan Chancellor's on April 11, 2020 10:53 am:
> >> The tt.config values are needed to reproduce but I did not verify that
> >> ONLY tt.config was needed. Other than that, no, we
On Sat, 11 Apr 2020 at 20:45, Philippe Mathieu-Daudé wrote:
> Buffer overflows are security issues because they allow attacker to
> arbitrarily write data in the process memory, and eventually take
> control of it. When attacker takes control, it can access underlying
> private data.
Note that
Yeah, our systick implementation is broken; I've known about this for
ages but never got round to trying to work through what the right way to
implement the behaviour is. I do have some more time to work on
M-profile stuff coming up at some point so I might get round to this if
nobody else does
On 4/11/20 11:29 AM, Peter Maydell wrote:
> If we are not making warnings fatal for compilation, make them
> non-fatal when building the Sphinx documentation also. (For instance
> Sphinx 3.0 warns about some constructs that older versions were happy
> with, which is a build failure if we use the
On 4/11/20 11:29 AM, Peter Maydell wrote:
> When kernel-doc generates a 'c:function' directive for a function
> one of whose arguments is a function pointer, it fails to print
> the close-paren after the argument list of the function pointer
> argument, for instance:
> .. c:function:: void
Public bug reported:
QEMU's emuation of SysTick on ARM is incorrect with respect to reload
behavior. This issue is described here, and also in a repository
dedicated to the issue:
https://github.com/oxidecomputer/qemu-systick-bug
(What follows is in Markdown, which I understand that
[Cc'ing Sebastian Bauer & Aurelien Jarno because I'm not sure the
problem was introduced by commit debc7e7dad1 or 07d8a50cb0e).
On 4/11/20 8:05 PM, BALATON Zoltan wrote:
> On Sat, 11 Apr 2020, Philippe Mathieu-Daudé wrote:
>> Zhang Zi Ming reported a heap overflow in the Drawing Engine of
>> the
I've sent a proposed fix to the list:
https://patchew.org/QEMU/20200411182934.28678-1-peter.mayd...@linaro.org/
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Richard Henderson writes:
> Will be used for SVE2 isa subset enablement.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alex Bennée
--
Alex Bennée
20:08 Sub, 11.04.2020. Richard Henderson је
написао/ла:
>
> On 4/11/20 5:46 AM, lixinyu wrote:
> > OPC_SYNC_WMB, OPC_SYNC_MB, OPC_SYNC_ACQUIRE, OPC_SYNC_RELEASE and
> > OPC_SYNC_RMB have wrong encode. According to the mips manual,
> > their encode should be 'OPC_SYNC | 0x?? << 6' rather than
> >
The kernel-doc Sphinx plugin and associated script currently emit
'c:type' directives for "struct foo" documentation.
Sphinx 3.0 warns about this:
/home/petmay01/linaro/qemu-from-laptop/qemu/docs/../include/exec/memory.h:3:
WARNING: Type must be either just a name or a typedef-like
If we are not making warnings fatal for compilation, make them
non-fatal when building the Sphinx documentation also. (For instance
Sphinx 3.0 warns about some constructs that older versions were happy
with, which is a build failure if we use the warnings-as-errors
flag.)
This provides a
Our current docs don't build with Sphinx 3, as noted in
https://bugs.launchpad.net/bugs/1872113 -- this is a combination of:
(1) we are using the sphinx-build -W option so warnings are treated
as errors
(3) a kernel-doc script bug meant it was omitting a close-paren
when a function
When kernel-doc generates a 'c:function' directive for a function
one of whose arguments is a function pointer, it fails to print
the close-paren after the argument list of the function pointer
argument, for instance:
.. c:function:: void memory_region_init_resizeable_ram (MemoryRegion * mr,
On 4/11/20 5:46 AM, lixinyu wrote:
> OPC_SYNC_WMB, OPC_SYNC_MB, OPC_SYNC_ACQUIRE, OPC_SYNC_RELEASE and
> OPC_SYNC_RMB have wrong encode. According to the mips manual,
> their encode should be 'OPC_SYNC | 0x?? << 6' rather than
> 'OPC_SYNC | 0x?? << 5'. Wrong encode can lead illegal instruction
>
On Sat, 11 Apr 2020, Philippe Mathieu-Daudé wrote:
Zhang Zi Ming reported a heap overflow in the Drawing Engine of
the SM501 companion chip model, in particular in the COPY_AREA()
macro in sm501_2d_operation().
As I have no idea what this code is supposed to do, add a simple
check to avoid the
On 3/31/20 12:50 PM, Philippe Mathieu-Daudé wrote:
> Philippe Mathieu-Daudé (7):
> hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to AHB PnP
> registers
> hw/misc/grlib_ahb_apb_pnp: Fix AHB PnP 8-bit accesses
Ping ^^^ for 5.0?
> hw/misc/grlib_ahb_apb_pnp: Add trace events on read
Hello Everyone,
I did some Benchmarking with iperf3 and memtester (to dirty some guest memory)
of colo performance in qemu 4.2.0 and in qemu 5.0.0-rc2
with my bugfixes on top.(
https://lists.nongnu.org/archive/html/qemu-devel/2020-04/msg01432.html )
I have taken the average over 4 runs.
On 4/10/20 3:08 PM, Stefano Garzarella wrote:
On Thu, Apr 09, 2020 at 10:15:27PM +0100, Alex Bennée wrote:
From: Peter Xu
We should only pass in gdb_get_reg16() with the GByteArray* object
itself, no need to shift. Without this patch, gdb remote attach will
crash QEMU.
Fixes: a010bdbe719
On Sat, 11 Apr 2020 at 14:04, Paolo Bonzini wrote:
>
> The following changes since commit 53ef8a92eb04ee19640f5aad3bff36cd4a36c250:
>
> Merge remote-tracking branch
> 'remotes/pmaydell/tags/pull-target-arm-20200406' into staging (2020-04-06
> 12:36:45 +0100)
>
> are available in the Git
On Thu, 9 Apr 2020 at 18:42, Stefan Hajnoczi wrote:
>
> The following changes since commit 8bac3ba57eecc466b7e73dabf7d19328a59f684e:
>
> Merge remote-tracking branch 'remotes/rth/tags/pull-rx-20200408' into
> staging (2020-04-09 13:23:30 +0100)
>
> are available in the Git repository at:
>
>
Nicholas Piggin's on April 11, 2020 7:32 pm:
> Nathan Chancellor's on April 11, 2020 10:53 am:
>> The tt.config values are needed to reproduce but I did not verify that
>> ONLY tt.config was needed. Other than that, no, we are just building
>> either pseries_defconfig or powernv_defconfig with
You are right. Wrong choice of words.
However, the change is a breaking change from Sphinx.
See https://github.com/sphinx-
doc/sphinx/issues/7457#issuecomment-612413080
** Bug watch added: github.com/sphinx-doc/sphinx/issues #7457
https://github.com/sphinx-doc/sphinx/issues/7457
--
You
On 11/04/20 13:19, Daniel Brodsky wrote:
> Just making sure this patch didn't get lost.
> ping http://patchwork.ozlabs.org/patch/1266336/
The patch looks good, but it will be included in QEMU only after 5.0 is
released.
Thanks,
Paolo
From: Alexander Duyck
According to the documentation in memory.h a ROM memory region will be
backed by RAM for reads, but is supposed to go through a callback for
writes. Currently we were not checking for the existence of the rom_device
flag when determining if we could perform a direct write
No attempts to fix or update the text; these are left for the next
patch in the series.
Signed-off-by: Paolo Bonzini
---
docs/devel/atomics.rst | 446 +
docs/devel/atomics.txt | 403 -
docs/devel/index.rst | 1 +
3
Signed-off-by: Paolo Bonzini
---
docs/devel/rcu.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/devel/rcu.txt b/docs/devel/rcu.txt
index d83fed2f79..0ce15ba198 100644
--- a/docs/devel/rcu.txt
+++ b/docs/devel/rcu.txt
@@ -132,7 +132,7 @@ The core RCU API is small:
From: Bauerchen
In touch_all_pages, if the mutex is not taken around qemu_cond_broadcast,
qemu_cond_broadcast may be called before all touch page threads enter
qemu_cond_wait. In this case, the touch page threads wait forever for the
main thread to wake them up, causing a deadlock.
Some of the constraints on operand sizes have been relaxed, so adjust the
documentation.
Deprecate atomic_mb_read and atomic_mb_set; it is not really possible to
use them correctly because they do not interoperate with sequentially-consistent
RMW operations.
Finally, extend the memory barrier
From: Olaf Hering
With QEMU 4.0 an incompatible change was added to pc_piix, which makes it
practical impossible to migrate domUs started with qemu2 or qemu3 to
newer qemu versions. Commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea
added and enabled a new member "smbus_no_migration_support". In
From: Igor Mammedov
the former is not actually used by explicit backend, so instead of
silently ignoring the option in non valid context, exit with error.
Signed-off-by: Igor Mammedov
Message-Id: <20200409134133.11339-1-imamm...@redhat.com>
Signed-off-by: Paolo Bonzini
---
softmmu/vl.c | 5
The following changes since commit 53ef8a92eb04ee19640f5aad3bff36cd4a36c250:
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200406'
into staging (2020-04-06 12:36:45 +0100)
are available in the Git repository at:
git://github.com/bonzini/qemu.git tags/for-upstream
From: Bruce Rogers
With the module upgrades code change, the statically sized dirs array
can now overflow. Increase it's size by one, according to the new
maximum possible usage.
Fixes: bd83c861c0 ("modules: load modules from versioned /var/run dir")
Signed-off-by: Bruce Rogers
Message-Id:
Brice Goglin writes:
> Le 10/04/2020 à 14:33, Alex Bennée a écrit :
>> That was by inspection on my system which seems to truncate a lot
>> earlier. It would be nice to find where in the Linux kernel it is
>> output but I failed to grep the relevant function last night.
>
>
> It's in
Stefano Garzarella writes:
> On Thu, Apr 09, 2020 at 10:15:27PM +0100, Alex Bennée wrote:
>> From: Peter Xu
>>
>> We should only pass in gdb_get_reg16() with the GByteArray* object
>> itself, no need to shift. Without this patch, gdb remote attach will
>> crash QEMU.
>>
>> Fixes:
Peter Maydell writes:
> On Fri, 10 Apr 2020 at 16:17, Richard Henderson
> wrote:
>> Although why Alex didn't add his own R-b to my patch when merging it to his
>> branch, I don't know.
>
> I think this is one of those areas where different submaintainers
> have different work practices.
OPC_SYNC_WMB, OPC_SYNC_MB, OPC_SYNC_ACQUIRE, OPC_SYNC_RELEASE and
OPC_SYNC_RMB have wrong encode. According to the mips manual,
their encode should be 'OPC_SYNC | 0x?? << 6' rather than
'OPC_SYNC | 0x?? << 5'. Wrong encode can lead illegal instruction
errors. These instructions often appear with
I'm a bit confused: you say "however there are still errors" but the
build log you quote ends with "build succeeded, 4 warnings" and it looks
like it has indeed just produced warnings and continued.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
** Changed in: qemu
Status: New => Won't Fix
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1863441
Title:
cmd_mode_sense always reports 0x70, no CDROM present
Status in QEMU:
Won't Fix
On Fri, Apr 3, 2020 at 9:21 PM wrote:
>
> From: Daniel Brodsky
>
> - ran regexp "qemu_mutex_lock\(.*\).*\n.*if" to find targets
> - replaced result with QEMU_LOCK_GUARD if all unlocks at function end
> - replaced result with WITH_QEMU_LOCK_GUARD if unlock not at end
>
> Signed-off-by: Daniel
Signed-off-by: Claudio Fontana
---
Makefile | 6 --
1 file changed, 6 deletions(-)
diff --git a/Makefile b/Makefile
index 7be15eeb7c..00377f28b9 100644
--- a/Makefile
+++ b/Makefile
@@ -567,12 +567,6 @@ slirp/all: .git-submodule-status
CC="$(CC)" AR="$(AR)" LD="$(LD)"
v2 -> v3:
* changed into a 2 patch series; in the second patch we remove the old
compatibility gunks that were meant for removal some time after 4.1.
* renamed the libfdt PHONY rule to dtc/all, with the intent to make
existing working trees forward and backward compatible across the change.
when building dtc/libfdt, we were previously using dtc/Makefile,
which tries to build some artifacts that are not needed,
and can complain on stderr about the absence of tools that
are not required to build just libfdt.
Instead, build only the strict necessary to get libfdt.a .
Signed-off-by:
when building dtc/libfdt, we were previously using dtc/Makefile,
which tries to build some artifacts that are not needed,
and can complain on stderr about the absence of tools that
are not required to build just libfdt.
Instead, build only the strict necessary to get libfdt.a .
Signed-off-by:
Signed-off-by: Claudio Fontana
---
Makefile | 6 --
1 file changed, 6 deletions(-)
diff --git a/Makefile b/Makefile
index 7be15eeb7c..00377f28b9 100644
--- a/Makefile
+++ b/Makefile
@@ -567,12 +567,6 @@ slirp/all: .git-submodule-status
CC="$(CC)" AR="$(AR)" LD="$(LD)"
v2 -> v3:
* changed into a 2 patch series; in the second patch we remove the old
compatibility gunks that were meant for removal some time after 4.1.
* renamed the libfdt PHONY rule to dtc/all, with the intent to make
existing working trees forward and backward compatible across the change.
when building dtc/libfdt, we were previously using dtc/Makefile,
which tries to build some artifacts that are not needed,
and can complain on stderr about the absence of tools that
are not required to build just libfdt.
Instead, build only the strict necessary to get libfdt.a .
Signed-off-by:
Run some PCI commands to call the COPY_AREA() macro in
sm501_2d_operation(), and verify that there is no more
overflow as reported in BZ#1786026 [*].
The SM501 is used by the R2D-PLUS and aCube Sam460ex
machines, but since it is a PCI card and we already have
an easy way to test PCI daughter
I once setup a Bugzilla 'Component Watching' rule on 'QEMU + CVE',
and recently found a notification for BZ#1786026 about a heap
overflow in sm501_2d_operation():
https://bugzilla.redhat.com/show_bug.cgi?id=1786026
As this is from december I suppose there was some embargo that
recently expired.
Zhang Zi Ming reported a heap overflow in the Drawing Engine of
the SM501 companion chip model, in particular in the COPY_AREA()
macro in sm501_2d_operation().
As I have no idea what this code is supposed to do, add a simple
check to avoid the heap overflow. This fixes:
cache=none means to bypass host cache. So we can't remove O_DIRECT flag in
unconditionally in update_open_flags();
Signed-off-by: Catherine Ho
---
v2: Fix to keep flags unchanged if cache=none, otherwise changed the file
without O_DIRECT incorrectly.
tools/virtiofsd/passthrough_ll.c | 14
cache=none means to bypass host cache. So we can't remove O_DIRECT flag in
unconditionally in update_open_flags();
Signed-off-by: Catherine Ho
---
tools/virtiofsd/passthrough_ll.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git
58 matches
Mail list logo
