On Mon, May 18, 2020 at 07:03:56AM +0200, Markus Armbruster wrote:
> Cc: Cédric Le Goater
> Cc: David Gibson
> Cc: qemu-...@nongnu.org
> Signed-off-by: Markus Armbruster
Acked-by: David Gibson
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINT
Patchew URL: https://patchew.org/QEMU/20200518051945.8621-1-arm...@redhat.com/
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 ===
#!
Added amount of bytes transferred to the target VM by all VFIO devices
Signed-off-by: Kirti Wankhede
---
hw/vfio/common.c| 20
hw/vfio/migration.c | 10 +-
include/qemu/vfio-helpers.h | 3 +++
migration/migration.c | 12
monito
If device is not failover primary device call vfio_migration_probe()
and vfio_migration_finalize() functions for vfio-pci device to enable
migration for vfio PCI device which support migration.
Removed vfio_pci_vmstate structure.
Removed migration blocker from VFIO PCI device specific structure and
Call VFIO_IOMMU_DIRTY_PAGES ioctl to start and stop dirty pages tracking
for VFIO devices.
Signed-off-by: Kirti Wankhede
---
hw/vfio/migration.c | 36
1 file changed, 36 insertions(+)
diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
index b9bbe38e539c.
vfio_listener_log_sync gets list of dirty pages from container using
VFIO_IOMMU_GET_DIRTY_BITMAP ioctl and mark those pages dirty when all
devices are stopped and saving state.
Return early for the RAM block section of mapped MMIO region.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
h
Signed-off-by: Kirti Wankhede
---
memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/memory.c b/memory.c
index 52f1a4cd37f0..5b868fe5eab3 100644
--- a/memory.c
+++ b/memory.c
@@ -1788,7 +1788,7 @@ bool memory_region_is_ram_device(MemoryRegion *mr)
uint8_t memory_region_
Added migration state change notifier to get notification on migration state
change. These states are translated to VFIO device state and conveyed to vendor
driver.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/migration.c | 30 ++
hw/vfio/
With vIOMMU, IO virtual address range can get unmapped while in pre-copy
phase of migration. In that case, unmap ioctl should return pages pinned
in that range and QEMU should find its correcponding guest physical
addresses and report those dirty.
Note: This patch is not yet tested. I'm trying to
Added helper functions to get IOMMU info capability chain.
Added function to get migration capability information from that
capability chain for IOMMU container.
Similar change was proposed earlier:
https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg03759.html
Signed-off-by: Kirti Wankhede
Add optional method to get address limit IOMMU supports
Signed-off-by: Kirti Wankhede
---
hw/i386/intel_iommu.c | 9 +
include/exec/memory.h | 18 ++
memory.c | 11 +++
3 files changed, 38 insertions(+)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/i
Sequence during _RESUMING device state:
While data for this device is available, repeat below steps:
a. read data_offset from where user application should write data.
b. write data of data_size to migration region from data_offset.
c. write data_size which indicates vendor driver that data is wri
- Migration functions are implemented for VFIO_DEVICE_TYPE_PCI device in this
patch series.
- VFIO device supports migration or not is decided based of migration region
query. If migration region query is successful and migration region
initialization is successful then migration is supported
Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy
functions. These functions handles pre-copy and stop-and-copy phase.
In _SAVING|_RUNNING device state or pre-copy phase:
- read pending_bytes. If pending_bytes > 0, go through below steps.
- read data_offset - indicates k
These functions save and restore PCI device specific data - config
space of PCI device.
Tested save and restore with MSI and MSIX type.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/pci.c | 163 ++
include/hw/vfio/vfio-com
This function will be used for migration region.
Migration region is mmaped when migration starts and will be unmapped when
migration is complete.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
Reviewed-by: Cornelia Huck
---
hw/vfio/common.c | 30 ++
Define flags to be used as delimeter in migration file stream.
Added .save_setup and .save_cleanup functions. Mapped & unmapped migration
region from these functions at source during saving or pre-copy phase.
Set VFIO device state depending on VM's state. During live migration, VM is
running when .
VM state change handler gets called on change in VM's state. This is used to set
VFIO device state to _RUNNING.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/migration.c | 87 +++
hw/vfio/trace-events | 2 +
include/hw
Hook vfio_get_object callback for PCI devices.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
Suggested-by: Cornelia Huck
Reviewed-by: Cornelia Huck
---
hw/vfio/pci.c | 8
include/hw/vfio/vfio-common.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/hw/vfio/
Hi,
This Patch set adds migration support for VFIO devices in QEMU.
This Patch set include patches as below:
Patch 1:
- Define KABI for VFIO device for migration support for device state and newly
added ioctl definations to get dirty pages bitmap. This is a placeholder
patch.
Patch 2-4:
- Fe
Kernel header patches are being reviewed along with kernel side changes.
This patch is only for place holder.
This patch include all changes in vfio.h from above patch set
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
linux-headers/linux/vfio.h | 318 ++
Added migration capability in IOMMU info chain.
User application should check IOMMU info chain for migration capability
to use dirty page tracking feature provided by kernel module.
User application must check page sizes supported and maximum dirty
bitmap size returned by this capability structure
Added a check such that only singleton IOMMU groups can pin pages.
>From the point when vendor driver pins any pages, consider IOMMU group
dirty page scope to be limited to pinned pages.
To optimize to avoid walking list often, added flag
pinned_page_dirty_scope to indicate if all of the vfio_grou
IOMMU container maintains a list of all pages pinned by vfio_pin_pages API.
All pages pinned by vendor driver through this API should be considered as
dirty during migration. When container consists of IOMMU capable device and
all pages are pinned and mapped, then all pages are marked dirty.
Added
DMA mapped pages, including those pinned by mdev vendor drivers, might
get unpinned and unmapped while migration is active and device is still
running. For example, in pre-copy phase while guest driver could access
those pages, host device or vendor driver can dirty these mapped pages.
Such pages s
VFIO_IOMMU_DIRTY_PAGES ioctl performs three operations:
- Start dirty pages tracking while migration is active
- Stop dirty pages tracking.
- Get dirty pages bitmap. Its user space application's responsibility to
copy content of dirty pages from source to destination during migration.
To prevent
vfio_pfn.ref_count is always updated while holding iommu->lock, using
atomic variable is overkill.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
Reviewed-by: Eric Auger
Reviewed-by: Cornelia Huck
---
drivers/vfio/vfio_iommu_type1.c | 9 +
1 file changed, 5 insertions(+), 4 deleti
Hi,
This patch set adds:
* IOCTL VFIO_IOMMU_DIRTY_PAGES to get dirty pages bitmap with
respect to IOMMU container rather than per device. All pages pinned by
vendor driver through vfio_pin_pages external API has to be marked as
dirty during migration. When IOMMU capable device is present in
- Defined MIGRATION region type and sub-type.
- Defined vfio_device_migration_info structure which will be placed at the
0th offset of migration region to get/set VFIO device related
information. Defined members of structure and usage on read/write access.
- Defined device states and state tr
Calculate and cache pgsize_bitmap when iommu->domain_list is updated
and iommu->external_domain is set for mdev device.
Add iommu->lock protection when cached pgsize_bitmap is accessed.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
drivers/vfio/vfio_iommu_type1.c | 88 +
On Sun, 17 May 2020 19:39:24 +0200
Thomas Huth wrote:
> 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 |
On Sun, 17 May 2020 19:52:43 +0200
Thomas Huth wrote:
> 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/ta
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 bld/*-soft
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, Bu
"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 ast2600-
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
i
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 print_qom_compositi
"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 dev
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 a/hw/ppc
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 system
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 xlnx
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 compo
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 no
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 not
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 @@ stat
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: qemu-...@nongnu.
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
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 ""
+
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. Corr
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: Maintai
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 unplugged
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 not
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 insertion(+
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 missing
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 is
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é
>> > ---
>> > include
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 v
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 v
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. It
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
E1000E_RSSI
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 *, siz
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 implementatio
> 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 setup
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 dirty
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:
+#if
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 instructi
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
target/xtensa/cp
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
in
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 / Virt
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 ===
#! /b
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 AR
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 ===
#!/b
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
> > > > qc
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 ta
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(+)
> create
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 d
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 docs/s
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 1
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 --gi
** 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 n
1 - 100 of 164 matches
Mail list logo
