On Tue, Jul 11, 2023 at 07:27:42PM -0300, Fabiano Rosas wrote:
> Fabiano Rosas writes:
>
> > Add basic tests for file-based migration.
> >
> > Signed-off-by: Fabiano Rosas
> > Reviewed-by: Peter Xu
> > ---
> > tests/qtest/migration-test.c | 99
> > 1 file c
On 7/6/23 18:30, Andrey Drobyshev wrote:
Right now "qemu-img map" reports compressed blocks as containing data
but having no host offset. This is not very informative. Instead,
let's add another boolean field named "compressed" in case JSON output
mode is specified. This is achieved by utilizi
On 7/6/23 18:30, Andrey Drobyshev wrote:
Functions qcow2_get_host_offset(), get_cluster_offset(),
vmdk_co_block_status() explicitly report compressed cluster types when data
is compressed. However, this information is never passed further. Let's
make use of it by adding new BDRV_BLOCK_COMPRESSE
On 7/6/23 18:30, Andrey Drobyshev wrote:
The previous commit adds "compressed" boolean field to JSON output of
"qemu-img map" command. Let's tweak expected tests output accordingly.
Signed-off-by: Andrey Drobyshev
---
tests/qemu-iotests/122.out| 84
tests/qemu-
On Wed, Jul 12, 2023 at 2:54 PM Zhu, Lingshan
wrote:
>
>
> On 7/11/2023 3:34 PM, Jason Wang wrote:
>
>
>
> On Tue, Jul 11, 2023 at 3:25 PM Eugenio Perez Martin
> wrote:
>
>> On Tue, Jul 11, 2023 at 9:05 AM Jason Wang wrote:
>> >
>> > On Tue, Jul 11, 2023 at 12:09 PM Zhu, Lingshan
>> wrote:
>>
On 11.07.23 17:34, David Hildenbrand wrote:
One limitation of virtio-mem is that we cannot currently unplug virtio-mem
devices that have all memory unplugged from the VM.
Let's properly handle forced unplug (as can be triggered by the VM) and
add support for ordinary unplug (requests) of virtio-
From: Eric Auger
Update the script to import iommufd.h
Signed-off-by: Eric Auger
Signed-off-by: Yi Liu
Signed-off-by: Zhenzhong Duan
---
scripts/update-linux-headers.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/update-linux-headers.sh b/scripts/update-linu
From: Yi Liu
Move low-level iommu agnostic helpers to a separate helpers.c
file. They relate to regions, interrupts and device/region
capabilities.
Signed-off-by: Eric Auger
Signed-off-by: Yi Sun
Signed-off-by: Yi Liu
Signed-off-by: Zhenzhong Duan
---
hw/vfio/common.c | 569 ---
Signed-off-by: Zhenzhong Duan
---
linux-headers/linux/iommufd.h | 347 ++
linux-headers/linux/kvm.h | 13 +-
linux-headers/linux/vfio.h| 142 +-
3 files changed, 498 insertions(+), 4 deletions(-)
create mode 100644 linux-headers/linux/iommufd.
From: Yi Liu
Move all the code really dependent on the legacy VFIO container/group
into a separate file: container.c. What does remain in common.c is
the code related to VFIOAddressSpace and MemoryListeners and migration
general operations.
Move struct VFIOBitmap declaration to vfio-common.h als
So that it doesn't need to be moved into container.c as done
in following patch.
Signed-off-by: Zhenzhong Duan
---
hw/vfio/common.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index f7e4dc0cef..a1fb0dafda 100644
--- a/
With the introduction of iommufd, the Linux kernel provides a generic
interface for userspace drivers to propagate their DMA mappings to kernel
for assigned devices. This series does the porting of the VFIO devices
onto the /dev/iommu uapi and let it coexist with the legacy implementation.
This QE
From: Eric Auger
Introduce an iommufd object which allows the interaction
with the host /dev/iommu device.
The /dev/iommu can have been already pre-opened outside of qemu,
in which case the fd can be passed directly along with the
iommufd object:
This allows the iommufd object to be shared accr
From: Eric Auger
Introduce helper functions that isolate the code used for
VFIO_SPAPR_TCE_v2_IOMMU. This code reliance is IOMMU backend
specific whereas the rest of the code in the callers, ie.
vfio_listener_region_add|del is not.
Signed-off-by: Eric Auger
Signed-off-by: Yi Liu
Signed-off-by:
From: Eric Auger
Let the vfio-ccw device use vfio_attach_device() and
vfio_detach_device(), hence hiding the details of the used
IOMMU backend.
Also now all the devices have been migrated to use the new
vfio_attach_device/vfio_detach_device API, let's turn the
legacy functions into static functi
From: Eric Auger
We want the VFIO devices to be able to use two different
IOMMU callbacks, the legacy VFIO one and the new iommufd one.
Introduce vfio_[attach/detach]_device which aim at hiding the
underlying IOMMU backend (IOCTLs, datatypes, ...).
Once vfio_attach_device completes, the device
This adds "--enable-iommufd/--disable-iommufd" to enable or disable
iommufd support, enabled by default.
Signed-off-by: Zhenzhong Duan
---
meson.build | 6 ++
meson_options.txt | 2 ++
scripts/meson-buildoptions.sh | 3 +++
3 files changed, 11 insertions(+)
dif
Commit "vfio/container-base: Introduce [attach/detach]_device container
callbacks"
add support to link to address space, we can utilize it to simplify
vfio_viommu_preset().
Signed-off-by: Zhenzhong Duan
---
hw/vfio/as.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
di
From: Eric Auger
Let the vfio-platform device use vfio_attach_device() and
vfio_detach_device(), hence hiding the details of the used
IOMMU backend.
Signed-off-by: Eric Auger
Signed-off-by: Yi Liu
Signed-off-by: Zhenzhong Duan
---
hw/vfio/platform.c | 43 +++--
With a vfio device iterator added, we can make some migration and reset
related functions group agnostic.
E.x:
vfio_mig_active
vfio_migratable_device_num
vfio_devices_all_dirty_tracking
vfio_devices_all_device_dirty_tracking
vfio_devices_all_running_and_mig_active
vfio_devices_dma_logging_stop
vfio
From: Eric Auger
Let's turn attach/detach_device as container callbacks. That way,
their implementation can be easily customized for a given backend.
For the time being, only the legacy container is supported.
Signed-off-by: Eric Auger
Signed-off-by: Yi Liu
Signed-off-by: Zhenzhong Duan
---
...which will be used by both legacy and iommufd container.
Signed-off-by: Yi Liu
Signed-off-by: Zhenzhong Duan
---
hw/vfio/common.c | 50 ---
include/hw/vfio/vfio-common.h | 3 +++
2 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/hw
From: Eric Auger
Now we support two types of iommu backends, let's add the capability
to select one of them. This depends on whether an iommufd object has
been linked with the vfio-pci device:
if the user wants to use the legacy backend, it shall not
link the vfio-pci device with any iommufd obj
From: Yi Liu
Add the iommufd backend. The IOMMUFD container class is implemented
based on the new /dev/iommu user API. This backend obviously depends
on CONFIG_IOMMUFD.
So far, the iommufd backend doesn't support live migration yet due
to missing support in the host kernel.
Co-authored-by: Eric
This gives management tools like libvirt a chance to open the vfio
cdev with privilege and pass FD to qemu.
This way qemu never needs to have privilege to open a VFIO or iommu
cdev node.
There is no easy way to check if a device is mdev with FD passing,
so fail the x-balloon-allowed check uncondi
On 11.07.23 22:23, Stefan Hajnoczi wrote:
On Fri, Jun 09, 2023 at 10:33:16AM +0200, Hanna Czenczek wrote:
bdrv_pad_request() relies on requests' lengths not to exceed SIZE_MAX,
which bdrv_check_qiov_request() does not guarantee.
bdrv_check_request32() however will guarantee this, and both of
bd
From: Eric Auger
Let the vfio-ap device use vfio_attach_device() and
vfio_detach_device(), hence hiding the details of the used
IOMMU backend.
Signed-off-by: Eric Auger
Signed-off-by: Yi Liu
Signed-off-by: Zhenzhong Duan
---
hw/vfio/ap.c | 66 +++--
From: Yi Liu
Abstract the VFIOContainer to be a base object. It is supposed to be
embedded by legacy VFIO container and later on, into the new iommufd
based container.
The base container implements generic code such as code related to
memory_listener and address space management. The VFIOContain
As pci hot reset path need to reference pci specific functions
and data structures, adding container level callback functions
for legacy and iommufd BE and referencing those pci specific
func/data is no better than implementing reset support with
iommufd BE directly in pci.c
This way we can also s
From: Yi Liu
/dev/vfio/devices/vfioX may not exist. In that case it is still possible
to open /dev/char/$major:$minor instead. Add helper function to abstract
the cdev open.
Suggested-by: Jason Gunthorpe
Signed-off-by: Yi Liu
Signed-off-by: Zhenzhong Duan
---
MAINTAINERS | 6 +++
The way to get vfio device pointer is different between legacy
container and iommufd container, with iommufd backend support
added, it's time to add the iterator support for iommufd.
In order to implement it, a pointer to hwpt is added in vbasedev.
Signed-off-by: Zhenzhong Duan
---
hw/vfio/iomm
From: Yi Liu
As the file mostly contains code related to VFIOAddressSpaces and
MemoryListeners, let's rename it into as.c
Signed-off-by: Eric Auger
Signed-off-by: Yi Liu
Signed-off-by: Zhenzhong Duan
---
hw/vfio/{common.c => as.c} | 0
hw/vfio/meson.build| 2 +-
2 files changed, 1 in
According to the 82371FB documentation (82371FB.pdf, 2.3.9. BMIBA-BUS
MASTER INTERFACE BASE ADDRESS REGISTER, April 1997), the register is
32bit wide. To properly reset it to default values, all 32bit need to be
cleared. Bit #0 "Resource Type Indicator (RTE)" needs to be enabled.
The initial chang
On Wed, Jul 12 2023, Zhenzhong Duan wrote:
> Signed-off-by: Zhenzhong Duan
> ---
> linux-headers/linux/iommufd.h | 347 ++
> linux-headers/linux/kvm.h | 13 +-
> linux-headers/linux/vfio.h| 142 +-
> 3 files changed, 498 insertions(+), 4 dele
It is useful to extend the number of available PCIe devices to KVM guests
for passthrough scenarios and also to expose these models to a different
(big endian) architecture. Introduce a new config PCIE_DEVICES to select
models, Intel Ethernet adapters and one USB controller. These devices all
suppo
On 7/11/23 22:21, Mike Christie wrote:
What was the issue you are seeing?
Was it something like you get the UA. We retry then on one of the
retries the sense is not setup correctly, so the scsi error handler
runs? That fails and the device goes offline?
If you turn on scsi debugging you would s
On 7/10/23 21:40, Michael S. Tsirkin wrote:
Acked-by: Michael S. Tsirkin
Seems safest to revert, but I'll let storage guys decide whether to
queue this.
There are multiple possibilities:
1) it's a QEMU bug that can be fixed, so no need to revert.
2) there's both a QEMU and a Linux bug, but
Already when starting QEMU we perform one system reset that ends up
triggering virtio_mem_unplug_all() with no actual memory plugged yet.
That, in turn will trigger ram_block_discard_range() and perform some
other actions that are not required in that case.
Let's optimize virtio_mem_unplug_all() f
We're already looking at machine->device_memory when calling
build_srat_memory(), so let's simply avoid going via
PC_MACHINE_DEVMEM_REGION_SIZE to get the size and rely on
machine->device_memory directly.
Once machine->device_memory is set, we know that the size > 0. The code now
looks much more s
The following changes since commit 887cba855bb6ff4775256f7968409281350b568c:
configure: Fix cross-building for RISCV host (v5) (2023-07-11 17:56:09 +0100)
are available in the Git repository at:
https://github.com/davidhildenbrand/qemu.git tags/mem-2023-07-12
for you to fetch changes up to
Let's factor out (un)plug handling, to be reused from arm/virt code.
Provide stubs for the case that CONFIG_VIRTIO_MD is not selected because
neither virtio-mem nor virtio-pmem is enabled. While this cannot
currently happen for x86, it will be possible for arm/virt.
Message-ID: <20230711153445.51
Let's use our new helper functions. Note that virtio-pmem-pci is not
enabled for arm and, therefore, not compiled in.
Message-ID: <20230711153445.514112-4-da...@redhat.com>
Tested-by: Mario Casquero
Reviewed-by: Michael S. Tsirkin
Signed-off-by: David Hildenbrand
---
hw/arm/virt.c | 81 +++
While we fence unplug requests from the outside, the VM can still
trigger unplug of virtio based memory devices, for example, in Linux
doing on a virtio-mem-pci device:
# echo 0 > /sys/bus/pci/slots/3/power
While doing that is not really expected to work without harming the
guest OS (e.g., rem
Let's support unplug requests for virtio-md-pci devices that provide
a unplug_request_check() callback.
We'll wire that up for virtio-mem-pci next.
Message-ID: <20230711153445.514112-6-da...@redhat.com>
Tested-by: Mario Casquero
Reviewed-by: Michael S. Tsirkin
Signed-off-by: David Hildenbrand
In many cases, blindly unplugging a virtio-mem device is problematic. We
can only safely remove a device once:
* The guest is not expecting to be able to read unplugged memory
(unplugged-inaccessible == on)
* The virtio-mem device does not have memory plugged (size == 0)
* The virtio-mem device d
Let's use our new helper. While at it, use VIRT_HIGHMEM_BASE.
Cc: Xiaojuan Yang
Cc: Song Gao
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Song Gao
Signed-off-by: David Hildenbrand
Message-Id: <20230623124553.400585-6-da...@redhat.com>
Signed-off-by: David Hildenbrand
---
hw/loongarch/vi
Let's move memory_device_check_addable() and basic checks out of
memory_device_get_free_addr() directly into memory_device_pre_plug().
Separating basic checks from address assignment is cleaner and
prepares for further changes.
As all memory device users now use memory_devices_init(), and that
fu
Let's avoid iterating over all devices and simply track it in the
DeviceMemoryState.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: David Hildenbrand
Message-Id: <20230623124553.400585-11-da...@redhat.com>
Signed-off-by: David Hildenbrand
---
hw/mem/memory-device.c | 22 +++
Let's use our new helper and stop always allocating ms->device_memory.
Once allcoated, we're sure that the size > 0 and that the base was
initialized.
Adjust the code in pc_memory_init() to check for machine->device_memory
instead of pcmc->has_reserved_memory and machine->device_memory->base.
Cc:
To achieve desired "x-ignore-shared" functionality, we should not
discard all RAM when realizing the device and not mess with
preallocation/postcopy when loading device state. In essence, we should
not touch RAM content.
As "x-ignore-shared" gets set after realizing the device, we cannot
rely on t
There are no remaining users in the tree. Libvirt never used that
property and a quick internet search revealed no other users.
Further, we renamed that property already in commit f2ffbe2b7dd0
("pc: rename "hotplug memory" terminology to "device memory"") without
anybody complaining.
So let's jus
Let's use our new helper. We'll add the subregion to system RAM now
earlier. That shouldn't matter, because the system RAM memory region should
already be alive at that point.
Cc: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: David Hildenbrand
Message-Id: <20230623124553.4005
Let's unify the error messages, such that we can simply stop allocating
ms->device_memory if the size would be 0 (and there are no memory
devices ever).
The case of "not supported by the machine" should barely pop up either
way: if the machine doesn't support memory devices, it usually doesn't
cal
ram_block_discard_range() cannot possibly do the right thing in
MAP_PRIVATE file mappings in the general case.
To achieve the documented semantics, we also have to punch a hole into
the file, possibly messing with other MAP_PRIVATE/MAP_SHARED mappings
of such a file.
For example, using VM templat
Let's intrduce a new helper that we will use to replace existing memory
device setup code during machine initialization. We'll enforce that the
size has to be > 0.
Once all machines were converted, we'll only allocate ms->device_memory
if the size > 0.
Reviewed-by: Philippe Mathieu-Daudé
Signed-
Let's use our new helper and stop always allocating ms->device_memory.
There is no difference in common memory-device code anymore between
ms->device_memory being NULL or the size being 0. So we only have to
teach spapr code that ms->device_memory isn't always around.
We can now modify two maxram_
Let's support device unplug by forwarding the unplug_request_check()
callback to the virtio-mem device.
Further, disallow changing the requested-size once an unplug request is
pending.
Disallowing requested-size changes handles corner cases such as
(1) pausing the VM (2) requesting device unplug
Let's add a new abstract "virtio memory device" type, and use it as
parent class of virtio-mem-pci and virtio-pmem-pci.
Message-ID: <20230711153445.514112-2-da...@redhat.com>
Tested-by: Mario Casquero
Reviewed-by: Michael S. Tsirkin
Signed-off-by: David Hildenbrand
---
MAINTAINERS
Tue, 11 Apr 2023 12:17:09 +0200 Gerd Hoffmann :
> +++ b/roms/Makefile
> +edk2-basetools:
> + python3 edk2-build.py --config edk2-build.config -m none
I think that needs to be $(PYTHON), because plain 'python3' may not be the
required python version.
In addition, a global EDK2_OPTIONS may al
virtio-mem wants to know whether it should not mess with the RAMBlock
content (e.g., discard RAM, preallocate memory) on incoming migration.
So let's expose that function as migrate_ram_is_ignored() in
migration/misc.h
Message-ID: <20230706075612.67404-4-da...@redhat.com>
Acked-by: Peter Xu
Test
On Tue, Jul 11, 2023 at 01:41:31PM -0400, Stefan Hajnoczi wrote:
On Tue, 11 Jul 2023 at 13:06, Stefano Garzarella wrote:
CCing `./scripts/get_maintainer.pl -f drivers/scsi/virtio_scsi.c`,
since I found a few things in the virtio-scsi driver...
FYI we have seen that Linux has problems with a Q
Hello Shawn,
On 7/12/23 00:24, Shawn Anastasio wrote:
Change radix64_set_rc to always generate a storage interrupt when the
R/C bits are not set appropriately instead of setting the bits itself.
According to the ISA both behaviors are valid, but in practice this
change more closely matches behav
On 7/11/23 19:06, Stefano Garzarella wrote:
CCing `./scripts/get_maintainer.pl -f drivers/scsi/virtio_scsi.c`,
since I found a few things in the virtio-scsi driver...
FYI we have seen that Linux has problems with a QEMU patch for the
virtio-scsi device (details at the bottom of this email in the
Hi Alex,
On 6/23/23 20:52, Alex Bennée wrote:
Cédric Le Goater writes:
Hello Anushree,
On 6/23/23 13:09, Anushree Mathur wrote:
Hi everyone,
I was trying to boot rhel9.3 image with upstream qemu-system-ppc64
-smp 2 option and observed a segfault (qemu crash).
qemu command line used:
qemu-sy
On Tue, Jul 11, 2023 at 06:21:31PM -0300, Fabiano Rosas wrote:
> This wasn't noticed because the test is currently disabled.
>
> Signed-off-by: Fabiano Rosas
> Fixes: 02f56e3de ("tests/qtest: massively speed up migration-test")
> ---
> tests/qtest/migration-test.c | 2 +-
> 1 file changed, 1 ins
07.07.2023 12:38, Daniel P. Berrangé wrote:
On Fri, Jul 07, 2023 at 01:30:16PM +0400, Marc-André Lureau wrote:
...>>> @@ -378,6 +380,10 @@ static int qio_channel_tls_close(QIOChannel *ioc,
{
QIOChannelTLS *tioc = QIO_CHANNEL_TLS(ioc);
+if (tioc->hs_ioc_tag) {
+g_source_remo
Currently, the vhost-user documentation says that rings are to be
initialized in a disabled state when VHOST_USER_F_PROTOCOL_FEATURES is
negotiated. However, by the time of feature negotiation, all rings have
already been initialized, so it is not entirely clear what this means.
At least the vhos
>-Original Message-
>From: Cornelia Huck
>Sent: Wednesday, July 12, 2023 3:49 PM
>Subject: Re: [RFC PATCH v4 02/24] Update linux-header per VFIO device cdev
>v14
>
>On Wed, Jul 12 2023, Zhenzhong Duan wrote:
>
>> Signed-off-by: Zhenzhong Duan
>> ---
>> linux-headers/linux/iommufd.h | 34
On Wed, Jul 12 2023, "Duan, Zhenzhong" wrote:
>>-Original Message-
>>From: Cornelia Huck
>>Sent: Wednesday, July 12, 2023 3:49 PM
>>Subject: Re: [RFC PATCH v4 02/24] Update linux-header per VFIO device cdev
>>v14
>>
>>On Wed, Jul 12 2023, Zhenzhong Duan wrote:
>>
>>> Signed-off-by: Zhen
>-Original Message-
>From: Cornelia Huck
>Sent: Wednesday, July 12, 2023 5:36 PM
>Subject: RE: [RFC PATCH v4 02/24] Update linux-header per VFIO device cdev
>v14
>
>On Wed, Jul 12 2023, "Duan, Zhenzhong"
>wrote:
>
>>>-Original Message-
>>>From: Cornelia Huck
>>>Sent: Wednesday
04.07.2023 12:39, Mauro Matteo Cascella wrote:
On Tue, Jul 4, 2023 at 11:03 AM Marc-André Lureau
wrote:
On Tue, Jul 4, 2023 at 10:42 AM Mauro Matteo Cascella
wrote:
A wrong exit condition may lead to an infinite loop when inflating a
valid zlib buffer containing some extra bytes in the `
On 7/12/2023 3:22 PM, Jason Wang wrote:
On Wed, Jul 12, 2023 at 2:54 PM Zhu, Lingshan
wrote:
On 7/11/2023 3:34 PM, Jason Wang wrote:
On Tue, Jul 11, 2023 at 3:25 PM Eugenio Perez Martin
wrote:
On Tue, Jul 11, 2023 at 9:05 AM Jason Wang
wrote:
>
On Wed, Jul 12, 2023 at 10:06:56AM +0200, Paolo Bonzini wrote:
On 7/11/23 22:21, Mike Christie wrote:
What was the issue you are seeing?
Was it something like you get the UA. We retry then on one of the
retries the sense is not setup correctly, so the scsi error handler
runs? That fails and the
On Wed, Jul 12, 2023 at 10:35:48AM +0200, Paolo Bonzini wrote:
On 7/11/23 19:06, Stefano Garzarella wrote:
CCing `./scripts/get_maintainer.pl -f drivers/scsi/virtio_scsi.c`,
since I found a few things in the virtio-scsi driver...
FYI we have seen that Linux has problems with a QEMU patch for th
12.07.2023 05:13, Nicholas Piggin wrote:
On Tue Jul 11, 2023 at 6:59 PM AEST, Nicholas Piggin wrote:
The gdb remote protocol has a special interrupt character (0x03) that is
transmitted outside the regular packet processing, and represents a
Ctrl-C pressed in the client. Despite not being a regu
11.07.2023 04:48, Hawkins Jiawei wrote:
..
Sorry for not mentioning that I have moved the patch to the patch series
titled "Vhost-vdpa Shadow Virtqueue _F_CTRL_RX commands support" at [1].
The reason for this move is that the bug in question should not be
triggered until the VIRTIO_NET_CTRL_MAC_T
Hi Cédric,
On 12/7/23 10:01, Cédric Le Goater wrote:
It is useful to extend the number of available PCIe devices to KVM guests
for passthrough scenarios and also to expose these models to a different
(big endian) architecture. Introduce a new config PCIE_DEVICES to select
models, Intel Ethernet
On 12/7/23 09:47, Olaf Hering wrote:
According to the 82371FB documentation (82371FB.pdf, 2.3.9. BMIBA-BUS
MASTER INTERFACE BASE ADDRESS REGISTER, April 1997), the register is
32bit wide. To properly reset it to default values, all 32bit need to be
cleared. Bit #0 "Resource Type Indicator (RTE)"
On 11/7/23 19:58, Daniel P. Berrangé wrote:
On Tue, Jul 11, 2023 at 04:49:20PM +0200, Philippe Mathieu-Daudé wrote:
Refresh the generated files by running:
$ make lcitool-refresh
Signed-off-by: Philippe Mathieu-Daudé
---
tests/docker/dockerfiles/debian-amd64.docker | 2 -
tests/docker/
On 11/7/23 21:39, Warner Losh wrote:
On Tue, Jul 11, 2023 at 8:49 AM Philippe Mathieu-Daudé
mailto:phi...@linaro.org>> wrote:
Add the generate_pkglist() helper to generate a list of packages
required by a distribution to build QEMU.
Since we can not add a "THIS FILE WAS AUTO-GENERA
On Wed, Jul 12, 2023 at 01:00:38PM +0200, Philippe Mathieu-Daudé wrote:
> On 11/7/23 19:58, Daniel P. Berrangé wrote:
> > On Tue, Jul 11, 2023 at 04:49:20PM +0200, Philippe Mathieu-Daudé wrote:
> > > Refresh the generated files by running:
> > >
> > >$ make lcitool-refresh
> > >
> > > Signed-
RFC:
https://lists.nongnu.org/archive/html/qemu-devel/2023-03/msg04263.html
v1:
https://lists.nongnu.org/archive/html/qemu-devel/2023-04/msg01575.html
Based-on: <20230711155230.64277-1-hre...@redhat.com>
(“[PATCH 0/6] vhost-user: Add suspend/resume”)
https://lists.nongnu.org/archive/htm
A virtio-fs device's VM state consists of:
- the virtio device (vring) state (VMSTATE_VIRTIO_DEVICE)
- the back-end's (virtiofsd's) internal state
We get/set the latter via the new vhost operations to transfer migratory
state. It is its own dedicated subsection, so that for external
migration, it
For vhost-user devices, qemu can migrate the virtio state, but not the
back-end's internal state. To do so, we need to be able to transfer
this internal state between front-end (qemu) and back-end.
At this point, this new feature is added for the purpose of virtio-fs
migration. Because virtiofsd
On Wed, Jul 12, 2023 at 11:17:04AM +0200, Hanna Czenczek wrote:
> Currently, the vhost-user documentation says that rings are to be
> initialized in a disabled state when VHOST_USER_F_PROTOCOL_FEATURES is
> negotiated. However, by the time of feature negotiation, all rings have
> already been init
vhost_save_backend_state() and vhost_load_backend_state() can be used by
vhost front-ends to easily save and load the back-end's state to/from
the migration stream.
Because we do not know the full state size ahead of time,
vhost_save_backend_state() simply reads the data in 1 MB chunks, and
writes
Add the interface for transferring the back-end's state during migration
as defined previously in vhost-user.rst.
Signed-off-by: Hanna Czenczek
---
include/hw/virtio/vhost-backend.h | 24 +
include/hw/virtio/vhost.h | 79
hw/virtio/vhost-user.c| 147 +++
On 7/4/23 12:32, Thomas Huth wrote:
On 30/06/2023 11.17, Pierre Morel wrote:
The topology information are attributes of the CPU and are
specified during the CPU device creation.
On hot plug we:
- calculate the default values for the topology for drawers,
books and sockets in the case they
On 12.07.23 13:17, Michael S. Tsirkin wrote:
On Wed, Jul 12, 2023 at 11:17:04AM +0200, Hanna Czenczek wrote:
Currently, the vhost-user documentation says that rings are to be
initialized in a disabled state when VHOST_USER_F_PROTOCOL_FEATURES is
negotiated. However, by the time of feature negot
Current SR/IOV implementations assume that hardcoded Function numbers
are always available and will not conflict. It is somewhat non-trivial
to make the Function numbers to use controllable to avoid Function
number conflicts so ensure there is only one PF to make the assumption
hold true.
Also war
On 2023/07/11 11:56, Gurchetan Singh wrote:
This modifies the common virtio-gpu.h file have the fields and
defintions needed by gfxstream/rutabaga, by VirtioGpuRutabaga.
s/VirtioGpuRutabaga/VirtIOGPURutabaga/g since VirtIOGPU is spelled this
way everywhere else.
- a colon separated list of
Matheus Tavares Bernardino wrote:
>
> Subject: [PATCH v3] Hexagon: move GETPC() calls to top level helpers
Apologies, I had some problems with my send-email and server
configuration, thus ended up sending this v3 multiple times. Please
ignore the others and consider only this one (i.e.
https://lo
Hi
Looks good.
Reviewed-by: sai.pavan.bo...@amd.com
Regards,
Sai Pavan
>-Original Message-
>From: Francisco Iglesias
>Sent: Monday, July 10, 2023 7:33 PM
>To: qemu-devel@nongnu.org
>Cc: frasse.igles...@gmail.com; alist...@alistair23.me;
>edgar.igles...@gmail.com; peter.mayd...@linaro.or
On Wed, Jul 12, 2023 at 08:27:32PM +0900, Akihiko Odaki wrote:
> Current SR/IOV implementations assume that hardcoded Function numbers
> are always available and will not conflict. It is somewhat non-trivial
> to make the Function numbers to use controllable to avoid Function
> number conflicts so
On 2023/07/12 20:46, Michael S. Tsirkin wrote:
On Wed, Jul 12, 2023 at 08:27:32PM +0900, Akihiko Odaki wrote:
Current SR/IOV implementations assume that hardcoded Function numbers
are always available and will not conflict. It is somewhat non-trivial
to make the Function numbers to use controlla
On Wed, Jul 12, 2023 at 08:50:32PM +0900, Akihiko Odaki wrote:
> On 2023/07/12 20:46, Michael S. Tsirkin wrote:
> > On Wed, Jul 12, 2023 at 08:27:32PM +0900, Akihiko Odaki wrote:
> > > Current SR/IOV implementations assume that hardcoded Function numbers
> > > are always available and will not conf
> According to the 82371FB documentation (82371FB.pdf, 2.3.9. BMIBA-BUS
> MASTER INTERFACE BASE ADDRESS REGISTER, April 1997), the register is
> 32bit wide. To properly reset it to default values, all 32bit need to be
> cleared. Bit #0 "Resource Type Indicator (RTE)" needs to be enabled.
Queued, t
> diff --git a/configs/devices/s390x-softmmu/default.mak
> b/configs/devices/s390x-softmmu/default.mak
> index f2287a133f36..2d5ff476e32a 100644
> --- a/configs/devices/s390x-softmmu/default.mak
> +++ b/configs/devices/s390x-softmmu/default.mak
> @@ -7,6 +7,7 @@
> #CONFIG_VFIO_CCW=n
> #CONFIG_VI
On Mon, Jul 10, 2023 at 4:02 PM Francisco Iglesias <
francisco.igles...@amd.com> wrote:
> Hi,
>
> This series adds support for the Configuration Frame Unit (CFU) and the
> Configuration Frame controllers (CFRAME) to the Xilinx Versal machine
> ([1], chapter 21) for emulaing bitstream loading and r
On 2023/07/11 11:56, Gurchetan Singh wrote:
This adds initial support for gfxstream and cross-domain. Both
features rely on virtio-gpu blob resources and context types, which
are also implemented in this patch.
gfxstream has a long and illustrious history in Android graphics
paravirtualization.
1 - 100 of 229 matches
Mail list logo
