This is the instrumentation mentioned in "[PATCH 00/24] Fixes around
device realization".
PATCH 2/5 might have value on its own. You tell me.
Shell script to smoke-test all machines:
#!/bin/sh
success=0
fail=0
ulimit -c 0
git-describe --dirty --match v\*
git-log --oneline -1
for i in
Signed-off-by: Markus Armbruster
---
hw/core/qdev.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 9e5538aeae..936ef3988a 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -98,6 +98,23 @@ void qdev_set_parent_bus(DeviceState *dev,
"info qom-tree" prints children in unstable order. This is a pain
when diffing output for different versions to find change. Print it
sorted.
Signed-off-by: Markus Armbruster
---
qom/qom-hmp-cmds.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
The number of CPUs is controlled by property "num-cpus".
aspeed_soc_ast2600_init() creates the maximum supported number.
aspeed_soc_ast2600_realize() realizes only the wanted number. Works,
although it leaves unrealized devices hanging around in the QOM
composition tree. Affects machines
Signed-off-by: Markus Armbruster
---
qdev-monitor.c | 4
1 file changed, 4 insertions(+)
diff --git a/qdev-monitor.c b/qdev-monitor.c
index 07f78e9f5d..ec4e134ff7 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -801,6 +801,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int
Signed-off-by: Markus Armbruster
---
qom/qom-hmp-cmds.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/qom/qom-hmp-cmds.c b/qom/qom-hmp-cmds.c
index cd08233a4c..4a61ee1b8c 100644
--- a/qom/qom-hmp-cmds.c
+++ b/qom/qom-hmp-cmds.c
@@ -91,6 +91,17 @@ static void
"info qtree" shows children in reverse creation order. Show them
sorted by QOM path.
Signed-off-by: Markus Armbruster
---
qdev-monitor.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/qdev-monitor.c b/qdev-monitor.c
index a4735d3bb1..07f78e9f5d
leon3_generic_hw_init() creates a "grlib,ahbpnp" and a "grlib,apbpnp"
sysbus device in a way that leaves them unplugged.
Create them the common way that puts them into the main system bus.
Affects machine leon3_generic. Visible in "info qtree":
bus: main-system-bus
type System
+
These devices go with the "via-pmu" device, which is controlled by
property "has-pmu". macio_newworld_init() creates it unconditionally,
because the property has not been set then. macio_newworld_realize()
realizes it only when the property is true. Works, although it can
leave an unrealized
object_property_set_bool(OBJECT(dev), true, "realized", ...) right
after qdev_init_nofail(dev) does nothing, because qdev_init_nofail()
already realizes. Drop.
Cc: BALATON Zoltan
Signed-off-by: Markus Armbruster
---
hw/ppc/ppc440_uc.c | 2 --
1 file changed, 2 deletions(-)
diff --git
riscv_sifive_e_soc_init(), riscv_sifive_u_soc_init(),
spike_board_init(), spike_v1_10_0_board_init(),
spike_v1_09_1_board_init(), and riscv_virt_board_init() create
"riscv-hart_array" sysbus devices in a way that leaves them unplugged.
Create them the common way that puts them into the main
This would have caught some of the bugs I just fixed.
Signed-off-by: Markus Armbruster
---
hw/core/qdev.c | 16
1 file changed, 16 insertions(+)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 0df995eb94..fe2dea8968 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -429,6
xlnx_dp_init() creates these two devices, but they're never realized.
Affects machine xlnx-zcu102.
I wonder how this ever worked. If the "device becomes real only on
realize" thing actually works, then we've always been missing these
two devices, yet nobody noticed.
Fix by realizing them in
The number of stacks is controlled by property "num-stacks".
pnv_pec_instance_init() creates the maximum supported number, because
the property has not been set then. pnv_pec_realize() realizes only
the wanted number. Works, although it can leave unrealized devices
hanging around in the QOM
sm501_init() and ati_vga_realize() create an "i2c-ddc" device, but
neglect to realize it. Affects machines sam460ex, shix, r2d, and
fulong2e.
I wonder how this ever worked. If the "device becomes real only on
realize" thing actually works, then we've always been missing the
device, yet nobody
cuda_init() creates a "mos6522-cuda" device, but it's never realized.
Affects machines mac99 with via=cuda (default) and g3beige.
pmu_init() creates a "mos6522-pmu" device, but it's never realized.
Affects machine mac99 with via=pmu and via=pmu-adb,
I wonder how this ever worked. If the "device
mac_via_realize() creates a "mos6522-q800-via1" and a
"mos6522-q800-via2" device, but neglects to realize them. Affects
machine q800.
I wonder how this ever worked. If the "device becomes real only on
realize" thing actually works, then we've always been missing these
two devices, yet nobody
These devices are optional, and enabled by property "enable-bitband".
armv7m_instance_init() creates them unconditionally, because the
property has not been set then. armv7m_realize() realizes them only
when the property is true. Works, although it leaves unrealized
devices hanging around in the
This would have caught some of the bugs I just fixed.
Signed-off-by: Markus Armbruster
---
hw/core/qdev.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 9e5538aeae..0df995eb94 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -97,6 +97,11 @@
These devices are optional, and controlled by @nb_nics.
aspeed_soc_ast2600_init() and aspeed_soc_init() create the maximum
supported number. aspeed_soc_ast2600_realize() and
aspeed_soc_realize() realize only the wanted number. Works, although
it can leave unrealized devices hanging around in the
The devices we plug into the macio-bus are all sysbus devices
(DeviceClass member bus_type is TYPE_SYSTEM_BUS), but macio-bus does
not derive from TYPE_SYSTEM_BUS. Fix that.
"info qtree" now shows the devices' mmio ranges, as it should
Cc: Mark Cave-Ayland
Cc: David Gibson
Cc:
macio_oldworld_init() creates a "macio-nvram", sysbus device, but
neglects to but it on a bus.
Put it on the macio bus. Affects machine g3beige. Visible in "info
qtree":
bus: macio.0
type macio-bus
[...]
+ dev: macio-nvram, id ""
+
Commit 260bc9d8aa "hw/sd/sd.c: QOMify" QOMified only the device
itself, not its users. It kept sd_init() around for non-QOMified
users.
More than four years later, three such users remain: omap1 (machines
cheetah, sx1, sx1-v1) and omap2 (machines n800, n810) are not
QOMified, and pl181 (machines
Device "riscv.sifive.e.soc" is a direct subtype of TYPE_DEVICE, but
its instance struct SiFiveESoCState's member @parent_obj is
SysBusDevice instead of DeviceState. Correct that.
Same for "riscv.sifive.u.soc"'s instance struct SiFiveUSoCState.
Cc: Palmer Dabbelt
Cc: Alistair Francis
Cc: Sagar
pnv_chip_power8_instance_init() creates a "pnv-psi-POWER8" sysbus
device in a way that leaves it unplugged.
pnv_chip_power9_instance_init() and pnv_chip_power10_instance_init()
do the same for "pnv-psi-POWER9" and "pnv-psi-POWER10", respectively.
These devices aren't actually sysbus devices.
Cc: Cédric Le Goater
Cc: David Gibson
Cc: qemu-...@nongnu.org
Signed-off-by: Markus Armbruster
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 47ef3139e6..074dc7f023 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1207,7 +1207,9 @@ S:
pnv_init() creates "power10_v1.0-pnv-chip", "power8_v2.0-pnv-chip",
"power8e_v2.1-pnv-chip", "power8nvl_v1.0-pnv-chip", or
"power9_v2.0-pnv-chip" sysbus devices in a way that leaves them
unplugged.
pnv_chip_power9_instance_init() creates a "pnv-xive" sysbus device in
a way that leaves it
stm32f405_soc_initfn() creates six such devices, but
stm32f405_soc_realize() realizes only one. Affects machine
netduinoplus2.
I wonder how this ever worked. If the "device becomes real only on
realize" thing actually works, then we've always been missing five of
six such devices, yet nobody
We plug aux-to-i2c-bridge into the aux-bus, even though its
DeviceClass member bus_type is null, not TYPE_AUX_BUS. Fix that by
deriving it from TYPE_AUX_SLAVE instead of TYPE_DEVICE.
Cc: KONRAD Frederic
Signed-off-by: Markus Armbruster
---
hw/misc/auxbus.c | 2 +-
1 file changed, 1
pxa2xx_mmci_init() creates a "pxa2xx-mmci" device, but neglects to
realize it. Affects machines akita, borzoi, connex, mainstone, spitz,
terrier, tosa, verdex, and z2.
I wonder how this ever worked. If the "device becomes real only on
realize" thing actually works, then we've always been
This fixes a bunch of bugs I ran into while reworking how qdevs plug
into buses. I instrumented the code a bit to flush out instances of
bug patterns. I'll post these hacks separately.
Impact is less than clear in places. Help with that is appreciated.
Markus Armbruster (24):
arm/stm32f405:
On May 14 06:45, Klaus Jensen wrote:
> From: Klaus Jensen
>
> First, since the device only supports MSI-X or pin-based interrupt, if
> MSI-X is not enabled, it should not accept interrupt vectors different
> from 0 when creating completion queues.
>
> Secondly, the irq_status NvmeCtrl member is
Gerd Hoffmann writes:
> On Fri, May 15, 2020 at 09:06:20AM +0200, Markus Armbruster wrote:
>> Watch this:
>>
>> $ aarch64-softmmu/qemu-system-aarch64 -S -nodefaults -accel qtest
>> -display none -M vexpress-a15 -audiodev none,id=foo
>> audio: Device lm4549: audiodev default parameter
Stefan Hajnoczi writes:
> On Fri, May 15, 2020 at 09:00:21AM +0200, Markus Armbruster wrote:
>> diff --git a/trace/simple.c b/trace/simple.c
>> index fc7106ec49..906391538f 100644
>> --- a/trace/simple.c
>> +++ b/trace/simple.c
>> @@ -302,10 +302,10 @@ static int st_write_event_mapping(void)
>>
Philippe Mathieu-Daudé writes:
> On Fri, May 15, 2020 at 8:07 AM Markus Armbruster wrote:
>>
>> Philippe Mathieu-Daudé writes:
>>
>> > We use the Object type all over the place.
>> > Forward declare it in "qemu/typedefs.h".
>> >
>> > Signed-off-by: Philippe Mathieu-Daudé
>> > ---
>> >
On Mon, May 18, 2020 at 10:39:52AM +0800, Xiang Zheng wrote:
> Hi Kirti and Yan,
>
> How can I test this patch series on my SR-IOV devices?
> I have looked through Yan's pathes for i40e VF live migration support：
> https://patchwork.kernel.org/patch/11375177/
>
I just updated the patches to
On 2020/5/11 下午12:21, Alexander Bulekov wrote:
On 200511 1204, Jason Wang wrote:
The sender of packet will be checked in the qemu_net_queue_purge() but
we use NetClientState not its peer when trying to purge the incoming
queue in qemu_flush_or_purge_packets(). This will trigger the assert
in
On 2020/5/15 下午11:16, Laurent Vivier wrote:
On 08/05/2020 04:57, Jason Wang wrote:
On 2020/5/7 下午7:49, Laurent Vivier wrote:
This new command shows internal status of a VirtQueue.
(vrings and indexes).
Signed-off-by: Laurent Vivier
It looks to me that packed virtqueue is not supported.
Public bug reported:
Hello,
While fuzzing, I found an input which triggers an assertion failure in
e1000e_write_lgcy_rx_descr:
qemu-system-i386: /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1283: void
e1000e_write_lgcy_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const
Public bug reported:
Hello,
While fuzzing, I found an input which triggers an assertion failure in
e1000e_write_rx_descr:
qemu-system-i386: /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1359: void
e1000e_write_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const
E1000E_RSSInfo *,
On 5/18/2020 8:09 AM, Xiang Zheng wrote:
Hi Kirti and Yan,
How can I test this patch series on my SR-IOV devices?
I have looked through Yan's pathes for i40e VF live migration support：
https://patchwork.kernel.org/patch/11375177/
However, I cannot find the detailed
> Great progress! Are you planning to contribute your escc2 to the
> upstream?
I would like to. While it didn't solve the console difficulties on
OpenSolaris variants, it's probably still a good idea to increment
Sun4u emulation towards being more faithful to hardware. It will take
me a few weeks
On 2020/5/16 上午11:20, Li Feng wrote:
Hi, Dima.
This abort is what I have mentioned in my previous email.
I have triggered this crash without any fix a week ago.
And I have written a test patch to let vhost_log_global_start return
int and propagate the error to up layer.
However, my change is a
On 2020/5/16 上午12:54, Dima Stepanov wrote:
On Thu, May 14, 2020 at 03:34:24PM +0800, Jason Wang wrote:
On 2020/5/13 下午5:47, Dima Stepanov wrote:
case CHR_EVENT_CLOSED:
/* a close event may happen during a read/write, but vhost
* code assumes the vhost_dev remains
Hi Kirti and Yan,
How can I test this patch series on my SR-IOV devices?
I have looked through Yan's pathes for i40e VF live migration support：
https://patchwork.kernel.org/patch/11375177/
However, I cannot find the detailed implementation about device state
saving/restoring and
Hey Marc-Andre,
I'm working on a patchset with changes to libvhost-user. I'm hitting the
following checkpatch error:
Checking 0011-Lift-max-ram-slots-limit-in-libvhost-user.patch...
WARNING: architecture specific defines should be avoided
#117: FILE: contrib/libvhost-user/libvhost-user.h:38:
After banging my head in a wall for tree or four days, I got the ac97 to
work on windows 98se applying something called "Auto-patcher for windows
98se" downloaded from retrosystemsrevival, then using the windows 95
"VXD_A406" driver updated manually by unpacking the executable and
picking the .inf
Hi, I've been patching TCG for my own purposes recently and I was
wondering a few things. That being:
- Is the TCG backend expected to handle bad cases for instructions? I
was wondering as I found a situation where a very large shift constant
reaches the backend and causes an illegal
Hello,
this series fixes simcall opcode behavior on the recent xtensa cores
making it nop rather than illegal instruction when semihosting is
disabled.
Max Filippov (2):
target/xtensa: fetch HW version from configuration overlay
target/xtensa: fix simcall for newer hardware
Xtensa architecture has features which behavior depends on hardware
version. Provide hardware version information to translators: add
XtensaConfig::hw_version and use XCHAL_HW_VERSION from configuration
overlay to initialize it.
Signed-off-by: Max Filippov
---
target/xtensa/cpu.h | 1 +
After Xtensa release RE.2 simcall opcode has become nop for the
hardware instead of illegal instruction.
Signed-off-by: Max Filippov
---
target/xtensa/translate.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
Have you seen the patch series I have posted on the qemu-devel mailing
list? "[PATCH v5 0/7] dwc-hsotg (aka dwc2) USB host controller emulation."
If you could test that and give your 'tested-by', it could help get the
patch series accepted. That would require you to download the latest Qemu
source
Has there been any progress? I'm using KVM for ubuntu 20.04 and would
love to have this feature.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1502613
Title:
[Feature Request] Battery Status /
On Thu, 2020-05-14 at 16:49 +0200, Max Reitz wrote:
> On 10.05.20 15:40, Maxim Levitsky wrote:
> > This allows more tests to be able to have same output on both qcow2 luks
> > encrypted images
> > and raw luks images
> >
> > Signed-off-by: Maxim Levitsky
> > Reviewed-by: Daniel P. Berrangé
> >
Patchew URL: https://patchew.org/QEMU/20200517164817.5371-1-f4...@amsat.org/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!
Patchew URL: https://patchew.org/QEMU/20200517164817.5371-1-f4...@amsat.org/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
export
Patchew URL: https://patchew.org/QEMU/20200517164817.5371-1-f4...@amsat.org/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
On Thu, 2020-05-14 at 16:30 +0200, Max Reitz wrote:
> On 10.05.20 15:40, Maxim Levitsky wrote:
> > Now that we have all the infrastructure in place,
> > wire it in the qcow2 driver and expose this to the user.
> >
> > Signed-off-by: Maxim Levitsky
> > Reviewed-by: Daniel P. Berrangé
> > ---
> >
On 15/05/2020 19.07, Philippe Mathieu-Daudé wrote:
> One might get caught trying to understand unexpected Makefile
> behavior. Trailing backslash can help to split very long lines,
> but are rather dangerous when nothing follow. Preserve other
> developers debugging time by removing this one.
>
>
On Thu, 2020-05-14 at 16:32 +0200, Max Reitz wrote:
> On 14.05.20 16:14, Daniel P. Berrangé wrote:
> > On Thu, May 14, 2020 at 04:09:59PM +0200, Max Reitz wrote:
> > > On 10.05.20 15:40, Maxim Levitsky wrote:
> > > > This implements the encryption key management using the generic code in
> > > >
On 5/17/20 4:30 PM, BALATON Zoltan wrote:
On Sun, 17 May 2020, Philippe Mathieu-Daudé wrote:
On 5/17/20 12:40 PM, Philippe Mathieu-Daudé wrote:
On 5/16/20 5:33 PM, BALATON Zoltan wrote:
On Sat, 16 May 2020, Alexander Bulekov wrote:
On 200516 1513, BALATON Zoltan wrote:
Finally, there is a
On Thu, 2020-05-14 at 15:36 +0200, Max Reitz wrote:
> On 10.05.20 15:40, Maxim Levitsky wrote:
> > Some qcow2 create options can't be used for amend.
> > Remove them from the qcow2 create options and add generic logic to detect
> > such options in qemu-img
> >
> > Signed-off-by: Maxim Levitsky
>
On 15/05/2020 17.15, Cornelia Huck wrote:
> Add a basic example for passing a dasd via vfio-ccw.
>
> Signed-off-by: Cornelia Huck
> ---
> docs/system/s390x/vfio-ccw.rst | 72 ++
> docs/system/target-s390x.rst | 1 +
> 2 files changed, 73 insertions(+)
>
On 15/05/2020 17.15, Cornelia Huck wrote:
> Add some basic info how to use 3270 devices.
>
> Signed-off-by: Cornelia Huck
> ---
> docs/system/s390x/3270.rst | 32
> docs/system/target-s390x.rst | 1 +
> 2 files changed, 33 insertions(+)
> create mode 100644
On 15/05/2020 17.15, Cornelia Huck wrote:
> Add some hints about "devno" rules.
>
> Signed-off-by: Cornelia Huck
> ---
> docs/system/s390x/css.rst| 86
> docs/system/target-s390x.rst | 1 +
> 2 files changed, 87 insertions(+)
> create mode 100644
On 15/05/2020 19.07, Philippe Mathieu-Daudé wrote:
> Reviewed-by: Richard Henderson
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Cc: Paolo Bonzini
> ---
> MAINTAINERS | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fd88a3de49..659092eb43
On 15/05/2020 19.07, Philippe Mathieu-Daudé wrote:
> The KVM files has been moved from target-ARCH to the target/ARCH/
> folder in commit fcf5ef2a. Fix the pathname expansion.
>
> Fixes: fcf5ef2a ("Move target-* CPU file into a target/ folder")
Oops, my bad. Sorry for that oversight!
> diff
** Summary changed:
- GVTd not working after upgrade to qemu-5.0.0
+ GVTd not working (black screen) after upgrade to qemu-5.0.0
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879175
Title:
GVTd
Public bug reported:
Hi QEMU team,
=== Problem Summary ===
I have recently upgraded from QEMU-3.1.0 to to QEMU-5.0.0 on Debian
Unstable. Unfortunately GVTd (legacy passthrough of the integrated intel
gpu) stopped working correctly. The guest can still see and loads the
driver for the GPU, but
нед, 17. мај 2020. у 15:19 Philippe Mathieu-Daudé је
написао/ла:
>
> Hi Aleksandar,
>
> On 5/17/20 11:23 AM, Aleksandar Markovic wrote:
> > Machine file names should not have prefix "mips_".
> >
> > Folong2 machine source file will be handled in a separate patch,
>
> Typo: "Fuloong2e"
>
> > to
When a function from the memory subsystem return a MemTxResult
to indicate that the transaction failed, this return value
must not be ignored by the caller. Mark all these functions
with the QEMU_WARN_UNUSED_RESULT attribute, to prevent users
to ignore possible failed transactions.
Signed-off-by:
Both address_space_read_cached_slow() and
address_space_write_cached_slow() return a MemTxResult type.
Do not discard it, return it to the caller.
Signed-off-by: Philippe Mathieu-Daudé
---
include/exec/memory.h | 19 +++
exec.c| 16
2 files
Various places ignore the MemTxResult indicator of
transaction failed. Some cases might be justified
(DMA?) while other are probably bugs. To avoid
ignoring transaction errors, suggestion is to mark
functions returning MemTxResult with
warn_unused_result attribute.
Philippe Mathieu-Daudé (2):
i.MX7 supports watchdog pretimeout interupts. With this commit,
the watchdog in mcimx7d-sabre is fully operational, including
pretimeout support.
Reviewed-by: Peter Maydell
Signed-off-by: Guenter Roeck
---
v3: Added Peter's Reviewed-by: tag
v2: No change
hw/arm/fsl-imx7.c | 11
With this commit, the watchdog on mcimx6ul-evk is fully operational,
including pretimeout support.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Guenter Roeck
---
v3: Added Philippe's Reviewed-by: tag
v2: No change
hw/arm/fsl-imx6ul.c | 10 ++
1 file changed, 10 insertions(+)
With this patch, the watchdog on i.MX31 emulations is fully operational.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Guenter Roeck
---
v3: No change
v2: Select WDT_IMX2 explicitly
Added Philippe's Reviewed-by: tag
hw/arm/Kconfig | 1 +
hw/arm/fsl-imx31.c | 6
With this patch applied, the watchdog in the sabrelite emulation
is fully operational, including pretimeout support.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Guenter Roeck
---
v3: Added Philippe's Reviewed-by: tag
v2: No change
hw/arm/fsl-imx6.c | 9 +
1 file changed, 9
Implement full support for the watchdog in i.MX systems.
Pretimeout support is optional because the watchdog hardware
on i.MX31 does not support pretimeouts.
Signed-off-by: Guenter Roeck
---
v3: Improve handling of write-once registers and bits
Stop timers in reset function
Use explicit
Instantiating PWM, CAN, CAAM, and OCOTP devices is necessary to avoid
crashes when booting mainline Linux.
Reviewed-by: Peter Maydell
Signed-off-by: Guenter Roeck
---
v3: Added Peter's Reviewed-by: tag
v2: "octop" -> "ocotp"
hw/arm/fsl-imx7.c | 24
With this commit, the watchdog on imx25-pdk is fully operational,
including pretimeout support.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Guenter Roeck
---
v3: No change
v2: Select WDT_IMX2 explicitly
Added Philippe's Reviewed-by: tag
hw/arm/Kconfig | 1 +
In preparation for a full implementation, move i.MX watchdog driver
from hw/misc to hw/watchdog. While at it, add the watchdog files
to MAINTAINERS.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Guenter Roeck
---
v3: No change
v2: Instead of auto-selecting WDT_IMX2 if IMX is enabled,
The current i.MX watchdog implementation only supports resets.
This patch series implements the full watchdog, including optional
pretimeout support.
Notable changes:
- The existing i.MX watchdog emulation (which only emulates syste resets)
is moved from hw/misc to hw/watchdog and renamed to
On 5/17/20 3:51 PM, no-re...@patchew.org wrote:
Patchew URL: https://patchew.org/QEMU/20200517113804.9063-1-f4...@amsat.org/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably
On Sun, 17 May 2020, Philippe Mathieu-Daudé wrote:
On 5/17/20 12:40 PM, Philippe Mathieu-Daudé wrote:
On 5/16/20 5:33 PM, BALATON Zoltan wrote:
On Sat, 16 May 2020, Alexander Bulekov wrote:
On 200516 1513, BALATON Zoltan wrote:
Finally, there is a tag documented for bug fixes:
Patchew URL: https://patchew.org/QEMU/20200517113804.9063-1-f4...@amsat.org/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
export
Patchew URL: https://patchew.org/QEMU/20200517113804.9063-1-f4...@amsat.org/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
Hi Aleksandar,
On 5/17/20 11:23 AM, Aleksandar Markovic wrote:
Machine file names should not have prefix "mips_".
Folong2 machine source file will be handled in a separate patch,
Typo: "Fuloong2e"
to avoid conflicts. That patch is pending integration into the
main tree.
Signed-off-by:
On 5/17/20 11:23 AM, Aleksandar Markovic wrote:
Aleksandar Rikalo wants to use a different email address from
now on.
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: Aleksandar Markovic
---
.mailmap| 3 ++-
MAINTAINERS | 12 ++--
2
On 5/17/20 12:40 PM, Philippe Mathieu-Daudé wrote:
On 5/16/20 5:33 PM, BALATON Zoltan wrote:
On Sat, 16 May 2020, Alexander Bulekov wrote:
On 200516 1513, BALATON Zoltan wrote:
According to docs bits 1 and 0 of MM_INDEX are hard coded to 0 so
unaligned access via this register should not be
On 2020/5/12 上午2:43, Laurent Vivier wrote:
>>
>> + IOCTL_SPECIAL(DRM_IOCTL_VERSION, IOC_RW, do_ioctl_drm,
>> +MK_PTR(MK_STRUCT(STRUCT_drm_version)))
>
> Add a blank line here.
>
OK, thanks.
>> #ifdef TARGET_TIOCSTART
>>IOCTL_IGNORE(TIOCSTART)
>>IOCTL_IGNORE(TIOCSTOP)
On Sun, May 17, 2020 at 9:57 AM wrote:
>
> I've written up a basic implementation of the SAB 82532 ESCC2 device
> and have written a patch for OpenBIOS to add it to the device tree. I
> still have the 16550A UART acting as ttya to avoid having to write an
> OpenBIOS device driver.
Great
Instead of accessing a device with an invalid short size,
return MEMTX_ERROR to indicate the transaction failed (as
the device won't accept the transaction anyway).
Reported by libFuzzer. sdhci_sdma_transfer_multi_blocks()
ends calling dma_memory_rw() with size < 4, while the DMA
MMIO regions are
As it is illegal to access a device with less that its
minimum valid size, also check for access_size_min.
Signed-off-by: Philippe Mathieu-Daudé
---
exec.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index 5162f0d12f..d3ec30f995 100644
---
Something noticed while debugging Alexander's bug report
"Hang with high CPU usage in sdhci_data_transfer":
https://bugs.launchpad.net/qemu/+bug/1878054
The flatview ignores the MemoryRegion minimum access size.
It seems related to a similar issue Julia had with PCI
devices.
Not sure it is safe
Hello all,
my intention would be to develop per-target, dynamically loadable accelerator
modules.
This would allow to distribute a single QEMU base binary, and then provide
accelerators as optional additional binary packages to install,
with the first separate optional package being TCG.
Damir:
Hm, must be some misconfiguration, then. My config for Linux VMs to utilize 3
out of the 4 CCXs. Important parts of the libvirt domain XML:
24
1
No, creating artificial NUMA nodes is, simply put, never a good solution
for CPUs that operate as a single NUMA node - which is the case for all
Zen2 CPUs (except maybe EPYCs? not sure about those).
You may workaround the L3 issue that way, but hit many new bugs/problems
by introducing multiple
Fix OUTL instructions incorrectly displayed as OUTW.
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/misc_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/misc_helper.c b/target/i386/misc_helper.c
index 7d61221024..b6b1d41b14 100644
---
** Description changed:
qemu 5.0.0, liburing1 0.6-3, Linux 5.6.0-1-686-pae (Debian)
Stack trace:
- Stack trace of thread 31002:
- #0 0xb7faf1cd __kernel_vsyscall (linux-gate.so.1 +
0x11cd)
- #1 0xb6c618e2
On 5/16/20 5:33 PM, BALATON Zoltan wrote:
On Sat, 16 May 2020, Alexander Bulekov wrote:
On 200516 1513, BALATON Zoltan wrote:
According to docs bits 1 and 0 of MM_INDEX are hard coded to 0 so
unaligned access via this register should not be possible.
This also fixes problems reported in bug
1 - 100 of 132 matches
Mail list logo
