On 2023/10/11 17:51, Daniel P. Berrangé wrote:
On Wed, Oct 11, 2023 at 04:03:09PM +0900, Akihiko Odaki wrote:
Make qemu-plugin.h consumable for C++ platform.
Signed-off-by: Akihiko Odaki
---
docs/devel/tcg-plugins.rst | 4
meson.build| 2 +-
include/qemu/qemu-plugin.
On 06/10/2023 14.39, Fabiano Rosas wrote:
When using two different QEMU binaries for migration testing, we'll
need to find what is the machine version that will work with both
binaries. Add a helper for that.
Signed-off-by: Fabiano Rosas
---
tests/qtest/migration-helpers.c | 24 ++
On 06/10/2023 14.39, Fabiano Rosas wrote:
Stop relying on defaults and select a machine explicitly for every
architecture.
This is a prerequisite for being able to select machine types for
migration using different QEMU binaries for source and destination.
Signed-off-by: Fabiano Rosas
---
te
Akihiko Odaki writes:
> Simplify GDBRegisterState by replacing num_regs and xml members with
> one member that points to GDBFeature.
>
> Signed-off-by: Akihiko Odaki
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
On 06/10/2023 14.39, Fabiano Rosas wrote:
Now that we can query more than one binary, the "starting QEMU..."
message can get a little noisy. Mute those messages unless we're
running with --verbose.
Only affects qtest_init() calls from within libqtest. The tests
continue to output as usual.
Sign
Akihiko Odaki writes:
> MISA limits are common for all instances of a RISC-V CPU class so they
> are better put into class.
>
> Signed-off-by: Akihiko Odaki
> ---
> +static void riscv_host_cpu_init(Object *obj)
> +{
> +CPURISCVState *env = &RISCV_CPU(obj)->env;
> riscv_cpu_add_user_p
On 11/10/2023 17.48, Akihiko Odaki wrote:
On 2023/10/11 17:51, Daniel P. Berrangé wrote:
On Wed, Oct 11, 2023 at 04:03:09PM +0900, Akihiko Odaki wrote:
Make qemu-plugin.h consumable for C++ platform.
Signed-off-by: Akihiko Odaki
---
docs/devel/tcg-plugins.rst | 4
meson.build
On 11/10/2023 17.38, Stefan Hajnoczi wrote:
On Wed, 11 Oct 2023 at 07:23, Michael Tokarev wrote:
From: Peter Maydell
In query_port() we pass the address of a local pvrdma_port_attr
struct to the rdma_query_backend_port() function. Unfortunately,
rdma_backend_query_port() wants a pointer to
On Wed, 11 Oct 2023 16:23:35 +0530
Ani Sinha wrote:
> pc_get_device_memory_range() finds the device memory size by calculating the
> difference between maxram and ram sizes. This calculation makes sense only
> when
> maxram is greater than the ram size. Make sure we check for that before
> call
On 2023/10/12 1:21, Thomas Huth wrote:
On 11/10/2023 17.48, Akihiko Odaki wrote:
On 2023/10/11 17:51, Daniel P. Berrangé wrote:
On Wed, Oct 11, 2023 at 04:03:09PM +0900, Akihiko Odaki wrote:
Make qemu-plugin.h consumable for C++ platform.
Signed-off-by: Akihiko Odaki
---
docs/devel/tcg-plu
Gunyah is an open-source Type-1 hypervisor, that is currently supported on ARM64
architecture. Source code for it can be obtained from:
https://github.com/quic/gunyah-hypervisor.
This patch series adds support for Gunyah hypervisor via a new
accelerator option, 'gunyah'. This patch series is base
gunyah.h containts UAPI definitions exported by Gunyah Linux kernel
driver. This file will be referenced by Gunyah accelerator driver in
Qemu.
Note: Gunyah Linux kernel driver is not yet merged in Linux kernel.
v14 of the patch series has been posted on mailing lists.
https://lore.kernel.org/lkml
Complete the cpu execution loop. At this time, we recognize exits
associated with only MMIO access. Future patches will add support for
recognizing other exit reasons, such as PSCI calls made by guest.
Signed-off-by: Srivatsa Vaddagiri
---
accel/gunyah/gunyah-accel-ops.c | 1 +
accel/gunyah/gu
Specify the location of device-tree and its size, as Gunyah requires the
device-tree to be parsed before VM can begin its execution.
Signed-off-by: Srivatsa Vaddagiri
---
MAINTAINERS | 1 +
hw/arm/virt.c | 6 ++
include/sysemu/gunyah.h | 7 +++
target/arm/gunyah.
Avoid dereferencing a NULL pointer that its_class_name() could return.
Signed-off-by: Srivatsa Vaddagiri
---
hw/arm/virt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index a13c658bbf..b55d5c7282 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
Customize device-tree with Gunyah specific properties. Some of these
properties include specification of doorbells that need to be created
and associated with various interrupts.
Signed-off-by: Srivatsa Vaddagiri
---
hw/arm/virt.c | 11 ++
include/sysemu/gunyah.h | 7
target/
Gunyah hypervisor supports several APIs for a host VM to assign some of
its memory to the VM being created.
Lend - assigned memory is made private to VM (host loses access)
Share - assigned memory is shared between host and guest VM
No APIs exist however, at this time, for a protected VM
Add a new accelerator, gunyah, with basic functionality of creating a
VM. Subsequent patches will add support for other functions required to
run a VM.
Signed-off-by: Srivatsa Vaddagiri
---
MAINTAINERS | 7 +++
accel/Kconfig | 3 +
accel/gunyah/gunyah-ac
Add 'protected-vm' and 'preshmem-size' properties that can be specified
for a VM.
Protected VMs are those that have 'protected-vm' property set. Their
memory cannot be accessed by their (potentially untrusted) host. They
are useful to run secure applications whose data should remain private
to the
On Thu, Oct 12, 2023 at 01:42:04AM +0900, Akihiko Odaki wrote:
> On 2023/10/12 1:21, Thomas Huth wrote:
> > On 11/10/2023 17.48, Akihiko Odaki wrote:
> > > On 2023/10/11 17:51, Daniel P. Berrangé wrote:
> > > > On Wed, Oct 11, 2023 at 04:03:09PM +0900, Akihiko Odaki wrote:
> > > > > Make qemu-plugi
IRQFD function allows registering of an @eventfd and @irq. @irq will be
injected inside guest when @eventfd is written into.
IOEVENTFD function allows registering an @eventfd and a guest physical
address, @addr, along with optional data. A poll() on @eventfd will be
woken up when guest attempts t
These are some work-arounds required temporarily until some limitations
with Gunyah hypervisor are addressed.
Signed-off-by: Srivatsa Vaddagiri
---
accel/gunyah/gunyah-all.c | 18 ++
hw/arm/boot.c | 3 ++-
hw/arm/virt.c | 3 ++-
include/sysemu/guny
Add gunyah.rst that provide some informaiton on how to build and test
'gunyah' accelerator with open-source Gunyah hypervisor.
Signed-off-by: Srivatsa Vaddagiri
---
MAINTAINERS| 1 +
docs/system/arm/gunyah.rst | 214 +
2 files changed, 215 in
Gunyah hypervisor supports emulation of a GICv3 compatible interrupt
controller. Emulation is handled by hypervisor itself, with Qemu being
allowed to specify some of the properties such as IO address at which
GICv3 should be mapped in guest address space. These properties are
conveyed to hyperviso
Hello Thomas,
Thanks for the review.
On 10/11/23 10:35, Thomas Huth wrote:
On 11/10/2023 17.13, Ninad Palsule wrote:
Added basic qtests for FSI model.
Signed-off-by: Ninad Palsule
---
v3:
- Added new qtest as per Cedric's comment.
V4:
- Remove MAINTAINER and documentation changes from th
* Srivatsa Vaddagiri [2023-10-11 16:52:24]:
> One of the subsequent versions of the patch is expected to be merged
> upstream soon, after this this change to 'update-linux-headers' can be
Sorry about the typo, will be fixed in next version!
s/this this/which, this
> run against the main Linux
On 10/5/23 22:41, Glenn Miles wrote:
Allow external devices to drive pca9552 input pins by adding
input GPIO's to the model. This allows a device to connect
its output GPIO's to the pca9552 input GPIO's.
In order for an external device to set the state of a pca9552
pin, the pin must first be co
On 10/10/23 15:46, Marc-André Lureau wrote:
Hi
On Tue, Oct 10, 2023 at 4:49 PM Cédric Le Goater wrote:
Hello,
On 10/9/23 08:32, marcandre.lur...@redhat.com wrote:
From: Marc-André Lureau
Hi,
Implement RAMFB migration, and add properties to enable it only on >= 8.2
machines, + a few relat
On Sun, 8 Oct 2023 01:47:39 +0530
wrote:
> From: Ankit Agrawal
>
> ACPI spec provides a scheme to associate "Generic Initiators" [1]
> (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with
> integrated compute or DMA engines GPUs) with Proximity Domains. This is
> achieved
On Sun, 8 Oct 2023 01:47:40 +0530
wrote:
> From: Ankit Agrawal
>
> NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows
> partitioning of the GPU device resources (including device memory) into
> several (upto 8) isolated instances. Each of the partitioned memory needs
> a de
On Sun, 8 Oct 2023 01:47:38 +0530
wrote:
> From: Ankit Agrawal
>
> The CPU cache coherent device memory can be added as NUMA nodes
> distinct from the system memory nodes. These nodes are associated
> with the device and Qemu needs a way to maintain this link.
>
> Introduce a new acpi-generic-
Hi Alex,
On 9/20/23 22:02, Alex Williamson wrote:
> On Wed, 13 Sep 2023 10:01:47 +0200
> Eric Auger wrote:
>
>> Now we retrieve the usable IOVA ranges from the host,
>> we now the physical IOMMU aperture and we can remove
>> the assumption of 64b IOVA space when calling
>> vfio_host_win_add().
>>
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any
user-visible changes.
signature.asc
Description: PGP signature
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any
user-visible changes.
signature.asc
Description: PGP signature
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any
user-visible changes.
signature.asc
Description: PGP signature
Hi Jonathan,
> -Original Message-
> From: Jonathan Cameron
> Sent: Monday, October 9, 2023 7:27 AM
> To: Ankit Agrawal
> Cc: Jason Gunthorpe ; alex.william...@redhat.com;
> c...@redhat.com; shannon.zha...@gmail.com; peter.mayd...@linaro.org;
> a...@anisinha.ca; berra...@redhat.com; edua.
Hi Vladimir,
On Fri, Oct 6, 2023 at 5:08 PM Vladimir Isaev
wrote:
>
> Hi Mayuresh,
>
> 25.09.2023 14:09, Mayuresh Chitale wrote:
> > As per the Priv and Smepmp specifications, certain bits such as the 'L'
> > bit of pmp entries and mseccfg.MML can only be cleared upon reset and it
> > is necessar
Collect iova range information if VFIO_IOMMU_TYPE1_INFO_CAP_IOVA_RANGE
capability is supported.
This allows to propagate the information though the IOMMU MR
set_iova_ranges() callback so that virtual IOMMUs
get aware of those aperture constraints. This is only done if
the info is available and the
A reserved region is a range tagged with a type. Let's directly use
the Range type in the prospect to reuse some of the library helpers
shipped with the Range type.
Signed-off-by: Eric Auger
Reviewed-by: David Hildenbrand
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Cédric Le Goater
---
The implementation populates the array of per IOMMUDevice
host reserved ranges.
It is forbidden to have conflicting sets of host IOVA ranges
to be applied onto the same IOMMU MR (implied by different
host devices).
In case the callback is called after the probe request has
been issues by the driv
Let's expose range_compare() in the header so that it can be
reused outside of util/range.c
Signed-off-by: Eric Auger
Reviewed-by: Philippe Mathieu-Daudé
---
v1 -> v2:
- Added Philippe's R-b
---
include/qemu/range.h | 6 ++
util/range.c | 6 +-
2 files changed, 7 insertions(+)
This applies on top of vfio-next:
https://github.com/legoater/qemu/, vfio-next branch
On x86, when assigning VFIO-PCI devices protected with virtio-iommu
we encounter the case where the guest tries to map IOVAs beyond 48b
whereas the physical VTD IOMMU only supports 48b. This ends up with
VFIO_MAP
Rename VirtIOIOMMU (nb_)reserved_regions fields with the "prop_" prefix
to highlight those fields are set through a property, at machine level.
They are IOMMU wide.
A subsequent patch will introduce per IOMMUDevice reserved regions
that will include both those IOMMU wide property reserved
regions
Add an IOMMUDevice 'probe_done' flag to record that the driver
already issued a probe request on that device.
This will be useful to double check host reserved regions aren't
notified after the probe and hence are not taken into account
by the driver.
Signed-off-by: Eric Auger
Suggested-by: Jean
Introduce resv_region_list_insert() helper which inserts
a new ReservedRegion into a sorted list of reserved region.
In case of overlap, the new region has higher priority and
hides the existing overlapped segments. If the overlap is
partial, new regions are created for parts which are not
overlapp
For the time being the per device reserved regions are
just a duplicate of IOMMU wide reserved regions. Subsequent
patches will combine those with host reserved regions, if any.
Signed-off-by: Eric Auger
---
v2 -> v3:
- do the initialization of the GList when creating the IOMMUDevice
instead
Up to now we were exposing to the RESV_MEM probe requests the
reserved memory regions set though the reserved-regions array property.
Combine those with the host reserved memory regions if any. Those
latter are tagged as RESERVED. We don't have more information about
them besides then cannot be ma
This helper will allow to convey information about valid
IOVA ranges to virtual IOMMUS.
Signed-off-by: Eric Auger
---
v2 -> v3:
- Pass a Glist instead
- Added a comment on memory_region_iommu_set_iova_ranges
- Removed R-b due to that change
---
include/exec/memory.h | 30 ++
This helper reverses a list of regions within a [low, high]
span, turning original regions into holes and original
holes into actual regions, covering the whole UINT64_MAX span.
Signed-off-by: Eric Auger
---
v2 -> v3:
- now operate on GList's. Fix the commit msg by mentionning
low/high params
Add unit tests for both resv_region_list_insert() and
range_inverse_array().
Signed-off-by: Eric Auger
---
v2 -> v3:
- conversion to new GList based protos
---
tests/unit/test-resv-mem.c | 318 +
tests/unit/meson.build | 1 +
2 files changed, 319 inser
Now we retrieve the usable IOVA ranges from the host,
we now the physical IOMMU aperture and we can remove
the assumption of 64b IOVA space when calling
vfio_host_win_add().
This works fine in general but in case of an IOMMU memory
region this becomes more tricky. For instance the virtio-iommu
MR
Previous commit cbec7eb76879d419e7dbf531ee2506ec0722e825
"migration/multifd: Compute transferred bytes correctly"
removed accounting for packet_len in non-rdma
case, but the next_packet_size only accounts for pages, not for
the header packet (normal_pages * PAGE_SIZE) that is being sent
as iov[0].
In migration rate limiting atomic operations are used
to read the rate limit variables and transferred bytes and
they are expensive. Check first if rate_limit_max is equal
to RATE_LIMIT_DISABLED and return false immediately if so.
Note that with this patch we will also will stop flushing
by not ca
Sometimes multifd sends just sync packet with no pages
(normal_num is 0). In this case the old value is being
preserved and being accounted for while only packet_len
is being transferred.
Reset it to 0 after sending and accounting for.
Signed-off-by: Elena Ufimtseva
Reviewed-by: Fabiano Rosas
--
Hello
While working and testing various live migration scenarios,
a few issues were found.
This is the version 2 of the changes with few non-functional
modifications minus the dropped patch.
I have dropped the patch [1/4] since the discussion with Fabiano
and his proposed changes:
https://www.mai
next_packet_size name is a bit misleading, so add more comments
where its defined.
We send data in two chunks in multifd thread:
- send the packet with normal (non-zero) guest pages offsets that are
dirty.
This uses the packet_len and we increment number of packets
for this thread that ar
Hi, this is a resend of a few patches that lingered behind in the past
months. They are all reviewed and tested.
patch 1 is the test for the file transport which missed the last pull;
patches 2-6 are two small refactorings to ram.c that are prerequisite
for the fixed ram work;
patch 7 enables th
Add basic tests for file-based migration.
Note that we cannot use test_precopy_common because that routine
expects it to be possible to run the migration live. With the file
transport there is no live migration because we must wait for the
source to finish writing the migration data to the file be
'rs' is not used in that function. It's a leftover from commit
9360447d34 ("ram: Use MigrationStats for statistics").
Reviewed-by: Peter Xu
Signed-off-by: Fabiano Rosas
---
migration/ram.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
It makes a bit more sense to have the zero page handling of xbzrle
right where we save the zero page.
Also invert the exit condition to remove one level of indentation
which makes the next patch easier to grasp.
Reviewed-by: Peter Xu
Signed-off-by: Fabiano Rosas
---
migration/ram.c | 35 ++
From: Nikolay Borisov
Extract the ramblock parsing code into a routine that operates on the
sequence of headers from the stream and another the parses the
individual ramblock. This makes ram_load_precopy() easier to
comprehend.
Signed-off-by: Nikolay Borisov
Reviewed-by: Philippe Mathieu-Daudé
We don't need the QEMUFile when we're already passing the
PageSearchStatus.
Reviewed-by: Peter Xu
Signed-off-by: Fabiano Rosas
---
migration/ram.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index cd765212af..c8474f6fd8 10064
We've found the source of flakiness in this test, so re-enable it.
Reviewed-by: Juan Quintela
Signed-off-by: Fabiano Rosas
---
tests/qtest/migration-test.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
We don't need to do this in two pieces. One single function makes it
easier to grasp, specially since it removes the indirection on the
return value handling.
Reviewed-by: Peter Xu
Signed-off-by: Fabiano Rosas
---
migration/ram.c | 46 +-
1 file chang
Am 8. Oktober 2023 17:56:48 UTC schrieb Chuck Zmudzinski :
>On 10/7/23 8:38 AM, Bernhard Beschow wrote:
>> This series consolidates the implementations of the PIIX3 and PIIX4 south
>> bridges and makes PIIX4 usable in the PC machine via an experimental command
>> line parameter. The motivation i
PCI functions are plugged on a PCI bus. They can only access
external memory regions via the bus.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/isa/i82378.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/isa/i82378.c b/hw/isa/i82378.c
index 63e0857208..95b45d0178 100644
--
PCI functions are plugged on a PCI bus. They can only access
external memory regions via the bus.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/bonito.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c
index ee6cb85e97.
PCI functions are plugged on a PCI bus. They can only
access external memory regions via the bus. Use the
corresponding pci_address_space() / pci_address_space_io()
for that.
Philippe Mathieu-Daudé (4):
hw/isa/i82378: Access memory regions via pci_address_space()
hw/isa/lpc_ich9: Access memory
PCI functions are plugged on a PCI bus. They can only access
external memory regions via the bus.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/sparc64/sun4u.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
index d908a38f73..c87
PCI functions are plugged on a PCI bus. They can only access
external memory regions via the bus.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/isa/lpc_ich9.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 3f59980aa0..213b667f9b
Elena Ufimtseva writes:
> next_packet_size name is a bit misleading, so add more comments
> where its defined.
> We send data in two chunks in multifd thread:
> - send the packet with normal (non-zero) guest pages offsets that are
>dirty.
>This uses the packet_len and we increment number
On Wed, 2023-10-11 at 19:05 +0200, Cédric Le Goater wrote:
> On 10/5/23 22:41, Glenn Miles wrote:
> > Allow external devices to drive pca9552 input pins by adding
> > input GPIO's to the model. This allows a device to connect
> > its output GPIO's to the pca9552 input GPIO's.
> >
> > In order for
Hi Anthony,
On Thu, Oct 05, 2023 at 11:40:57AM +0100, Anthony PERARD wrote:
> Hi Vikram,
>
> This patch prevent QEMU from been build with Xen 4.15. See comments.
>
> Also, why didn't you CC all the maintainers of
> include/hw/xen/xen_native.h?
I missed it. Initial version didn't have this file ch
On Wed, 2023-10-11 at 16:27 +0200, Cédric Le Goater wrote:
> On 9/27/23 22:32, Glenn Miles wrote:
> > The pca9552 INPUT0 and INPUT1 registers are supposed to
> > hold the logical values of the LED pins. A logical 0
> > should be seen in the INPUT0/1 registers for a pin when
> > its corresponding L
Virtual CPU hotplug support is being added across various architectures[1][3].
This series adds various code bits common across all architectures:
1. vCPU creation and Parking code refactor [Patch 1]
2. Update ACPI GED framework to support vCPU Hotplug [Patch 4,6,7]
3. ACPI CPUs AML code change [P
KVM vCPU creation is done once during the initialization of the VM when Qemu
thread is spawned. This is common to all the architectures.
Hot-unplug of vCPU results in destruction of the vCPU object in QOM but the
corresponding KVM vCPU object in the Host KVM is not destroyed and its
representative
CPU ctrl-dev MMIO region length could be used in ACPI GED and various other
architecture specific places. Move ACPI_CPU_HOTPLUG_REG_LEN macro to more
appropriate common header file.
Signed-off-by: Salil Mehta
Reviewed-by: Alex Bennée
Reviewed-by: Jonathan Cameron
Reviewed-by: Gavin Shan
Review
ACPI CPU hotplug related initialization should only happen if ACPI_CPU_HOTPLUG
support has been enabled for particular architecture. Add cpu_hotplug_hw_init()
stub to avoid compilation break.
Signed-off-by: Salil Mehta
Reviewed-by: Jonathan Cameron
Reviewed-by: Gavin Shan
Reviewed-by: Shaoqin H
CPUs Control device(\\_SB.PCI0) register interface for the x86 arch is based on
PCI and is IO port based and hence existing CPUs AML code assumes _CRS objects
would evaluate to a system resource which describes IO Port address. But on ARM
arch CPUs control device(\\_SB.PRES) register interface is m
ACPI GED(as described in the ACPI 6.2 spec) can be used to generate ACPI events
when OSPM/guest receives an interrupt listed in the _CRS object of GED. OSPM
then maps or demultiplexes the event by evaluating _EVT method.
This change adds the support of CPU hotplug event initialization in the
exist
ACPI GED shall be used to convey to the guest kernel about any CPU hot-(un)plug
events. Therefore, existing ACPI GED framework inside QEMU needs to be enhanced
to support CPU hotplug state and events.
Co-developed-by: Keqian Zhu
Signed-off-by: Keqian Zhu
Signed-off-by: Salil Mehta
Reviewed-by:
OSPM evaluates _EVT method to map the event. The CPU hotplug event eventually
results in start of the CPU scan. Scan figures out the CPU and the kind of
event(plug/unplug) and notifies it back to the guest. Update the GED AML _EVT
method with the call to \\_SB.CPUS.CSCN
Also, macro CPU_SCAN_METHOD
Virtual CPU Hot-unplug leads to unrealization of a CPU object. This also
involves destruction of the CPU AddressSpace. Add common function to help
destroy the CPU AddressSpace.
Signed-off-by: Salil Mehta
Tested-by: Vishnu Pajjuri
---
include/exec/cpu-common.h | 8
include/hw/core/cpu.
Add common function to help unregister the GDB Register Space. This shall be
done in context to the CPU unrealization.
Signed-off-by: Salil Mehta
Tested-by: Vishnu Pajjuri
---
gdbstub/gdbstub.c | 15 +++
include/exec/gdbstub.h | 5 +
2 files changed, 20 insertions(+)
diff
In vfio_realize, on the error path, we currently call
vfio_detach_device() after a successful vfio_attach_device.
While this looks natural, vfio_instance_finalize also induces
a vfio_detach_device(), and it seems to be the right place
instead as other resources are released there which happen
to be
Hi Zhenzhong,
On 10/11/23 03:33, Duan, Zhenzhong wrote:
> Hi Eric,
>
>> -Original Message-
>> From: Eric Auger
>> Sent: Monday, October 9, 2023 5:09 PM
>> Subject: [PATCH v5 07/15] vfio/pci: Introduce vfio_[attach/detach]_device
>>
>> We want the VFIO devices to be able to use two differen
Hi Vishnu
On 11/10/2023 12:08, Vishnu Pajjuri wrote:
Hi Salil,
On 11-10-2023 16:02, Salil Mehta wrote:
[...]
From: Vishnu Pajjuri
Sent: Wednesday, October 11, 2023 11:23 AM
To: Salil Mehta;qemu-devel@nongnu.org; qemu-
a...@nongnu.org
Cc:m...@kernel.org;jean-phili...@linaro.org; Jonathan Cam
On Wed, Oct 11, 2023 at 06:57:07PM +, Bernhard Beschow wrote:
>
>
> Am 8. Oktober 2023 17:56:48 UTC schrieb Chuck Zmudzinski :
> >On 10/7/23 8:38 AM, Bernhard Beschow wrote:
> >> This series consolidates the implementations of the PIIX3 and PIIX4 south
> >> bridges and makes PIIX4 usable in t
Fabiano Rosas wrote:
> Juan Quintela writes:
>
>> From: Fabiano Rosas
>>
>> There is currently no way to write a test for errors that happened in
>> qmp_migrate before the migration has started.
>>
>> Add a version of qmp_migrate that ensures an error happens. To make
>> use of it a test needs t
"Wang, Wei W" wrote:
> On Wednesday, October 11, 2023 8:41 PM, Juan Quintela wrote:
>> Wei Wang wrote:
>> > Current migration_completion function is a bit long. Refactor the long
>> > implementation into different subfunctions:
>> > - migration_completion_precopy: completion code related to preco
Reviewed-by: Peter Xu
Signed-off-by: Juan Quintela
---
migration/rdma.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/migration/rdma.c b/migration/rdma.c
index d3bba05262..932d4eda9b 100644
--- a/migration/rdma.c
+++ b/migration/rdma.c
@@ -3240,10 +3240,6 @@ static int
Once there:
- Remove unused data parameter
- unfold it in its callers
- change all callers to call qemu_rdma_registration_stop()
- We need to call QIO_CHANNEL_RDMA() after we check for migrate_rdma()
Reviewed-by: Peter Xu
Signed-off-by: Juan Quintela
---
This function has goto's. So I don't c
Helper to say if we are doing a migration over rdma.
Reviewed-by: Peter Xu
Signed-off-by: Juan Quintela
---
migration/migration.h | 2 ++
migration/options.h | 1 +
migration/migration.c | 1 +
migration/options.c | 7 +++
migration/rdma.c | 4 +++-
5 files changed, 14 insertions(+
Hi
In this version 3:
- rebased on top of master (markus changes affected a bit.)
- the patches that need to be reviewed are:
2-6: I have to do the QIO_CHANNEL_RDMA() dance after checking that rdma is
enabled.
11-13: I did some more cleanups,it should be only style changes, no
behav
Instead of going trhough ram_control_load_hook(), call
qemu_rdma_registration_handle() directly.
Reviewed-by: Peter Xu
Signed-off-by: Juan Quintela
---
migration/qemu-file.h | 1 -
migration/rdma.h | 3 +++
migration/ram.c | 5 -
migration/rdma.c | 12 +++-
4 file
The only user of ram_control_save_page() and save_page() hook was
rdma. Just move the function to rdma.c, rename it to
rdma_control_save_page().
Reviewed-by: Peter Xu
Signed-off-by: Juan Quintela
---
migration/qemu-file.h | 12
migration/rdma.h | 10 ++
migration/qemu-
There is only one flag called with: RAM_CONTROL_BLOCK_REG.
Reviewed-by: Peter Xu
Signed-off-by: Juan Quintela
---
migration/qemu-file.h | 11 ---
migration/rdma.h | 3 +++
migration/qemu-file.c | 10 --
migration/ram.c | 6 --
migration/rdma.c | 34
Once there, all the uses are local to the for, so declare the variable
inside the for statement.
Signed-off-by: Juan Quintela
---
migration/rdma.c | 49 ++--
1 file changed, 22 insertions(+), 27 deletions(-)
diff --git a/migration/rdma.c b/migration/r
Reviewed-by: Peter Xu
Signed-off-by: Juan Quintela
---
migration/qemu-file.h | 17 -
migration/rdma.h | 16
migration/ram.c | 2 +-
3 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/migration/qemu-file.h b/migration/qemu-file.h
index 0b
Declare all variables that are only used inside a for loop inside the
for statement.
This makes clear that they are not used outside of the for loop.
Signed-off-by: Juan Quintela
---
migration/rdma.c | 44 ++--
1 file changed, 18 insertions(+), 26 deletio
301 - 400 of 525 matches
Mail list logo
