From: Eugenio Pérez
This will make qemu aware of the device used buffers, allowing it to
write the guest memory with its contents if needed.
Signed-off-by: Eugenio Pérez
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
hw/virtio/vhost-shadow-virtqueue.c | 38 +++
On Mon, Mar 14, 2022 at 06:49:25PM +, Daniel P. Berrangé wrote:
> Taking a step back here and looking at the bigger picture of
> migration protocol configuration
>
> Almost every time we add a new feature to migration, we end up
> having to define at least one new migration parameter, then
From: Eugenio Pérez
This iova tree function allows it to look for a hole in allocated
regions and return a totally new translation for a given translated
address.
It's usage is mainly to allow devices to access qemu address space,
remapping guest's one into a new iova space where qemu can add ch
From: Eugenio Pérez
This function does the reverse operation of iova_tree_find: To look for
a mapping that match a translated address so we can do the reverse.
This have linear complexity instead of logarithmic, but it supports
overlapping HVA. Future developments could reduce it.
Signed-off-by
From: Eugenio Pérez
Setting the log address would make the device start reporting invalid
dirty memory because the SVQ vrings are located in qemu's memory.
Signed-off-by: Eugenio Pérez
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
hw/virtio/vhost-vdpa.c | 3 ++-
1 file changed,
From: Eugenio Pérez
Vhost shadow virtqueue (SVQ) is an intermediate jump for virtqueue
notifications and buffers, allowing qemu to track them. While qemu is
forwarding the buffers and virtqueue changes, it is able to commit the
memory it's being dirtied, the same way regular qemu's VirtIO devices
From: Eugenio Pérez
SVQ is able to log the dirty bits by itself, so let's use it to not
block migration.
Also, ignore set and clear of VHOST_F_LOG_ALL on set_features if SVQ is
enabled. Even if the device supports it, the reports would be nonsense
because SVQ memory is in the qemu region.
The l
From: Eugenio Pérez
Use translations added in VhostIOVATree in SVQ.
Only introduce usage here, not allocation and deallocation. As with
previous patches, we use the dead code paths of shadow_vqs_enabled to
avoid commiting too many changes at once. These are impossible to take
at the moment.
Sig
From: Eugenio Pérez
At this mode no buffer forwarding will be performed in SVQ mode: Qemu
will just forward the guest's kicks to the device.
Host memory notifiers regions are left out for simplicity, and they will
not be addressed in this series.
Signed-off-by: Eugenio Pérez
Acked-by: Michael
From: Eugenio Pérez
This is needed to achieve migration, so the destination can restore its
index.
Setting base as last used idx, so destination will see as available all
the entries that the device did not use, including the in-flight
processing ones.
This is ok for networking, but other kinds
From: Eugenio Pérez
This allows SVQ to negotiate features with the guest and the device. For
the device, SVQ is a driver. While this function bypasses all
non-transport features, it needs to disable the features that SVQ does
not support when forwarding buffers. This includes packed vq layout,
in
On Mon, Mar 14, 2022 at 09:27:38PM +0100, Philippe Mathieu-Daudé wrote:
> From: Philippe Mathieu-Daudé
>
> While I am not an experienced Darwin OS user, I now have to
> use a macOS based workstation and alike CI, meaning I should
> easily spot regressions and test fixes. I therefore volunteer
> t
Hello Steven,
[ ... ]
I was wondering if the following implementation is good to you.
1 Modify aspeed_scu_get_apb_freq() as below
uint32_t aspeed_scu_get_apb_freq(AspeedSCUState *s)
{
return ASPEED_SCU_GET_CLASS(s)->get_apb(s);
}
2. Introduce 2 APB class han
From: Eugenio Pérez
It reports the shadow virtqueue address from qemu virtual address space.
Since this will be different from the guest's vaddr, but the device can
access it, SVQ takes special care about its alignment & lack of garbage
data. It assumes that IOMMU will work in host_page_size ran
From: Eugenio Pérez
First half of the buffers forwarding part, preparing vhost-vdpa
callbacks to SVQ to offer it. QEMU cannot enable it at this moment, so
this is effectively dead code at the moment, but it helps to reduce
patch size.
Signed-off-by: Eugenio Pérez
Acked-by: Michael S. Tsirkin
S
From: Eugenio Pérez
Initial version of shadow virtqueue that actually forward buffers. There
is no iommu support at the moment, and that will be addressed in future
patches of this series. Since all vhost-vdpa devices use forced IOMMU,
this means that SVQ is not usable at this point of the series
From: Daniel Henrique Barboza
'prom-env-test' is a TCG test that will fail if QEMU is compiled with
--disable-tcg:
$ QTEST_QEMU_BINARY=./qemu-system-ppc64 ./tests/qtest/prom-env-test
/ppc64/prom-env/mac99: qemu-system-ppc64: -accel tcg: invalid accelerator tcg
(... hangs indefinitely ...)
Fix i
From: Daniel Henrique Barboza
'boot-serial-test' does not work with a QEMU built with --disable-tcg in
a IBM POWER9 host. The reason is that without TCG QEMU will default to
KVM acceleration, but then the KVM module in IBM POWER hosts aren't able
to handle other CPUs.
The result is that the test
From: Daniel Henrique Barboza
This test times out when running in an IBM POWER host and --disable-tcg.
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20220310183011.110391-10-danielhb...@gmail.com>
Signed-off-by: Cédric Le Goater
---
tests/avocado/ppc_virtex_ml507.py | 2 ++
1 file chang
From: Daniel Henrique Barboza
The PowerNV8/9 machines does not work with KVM acceleration, meaning
that boot_linux_console.py:BootLinuxConsole.test_ppc_powernv8/9 tests
will always fail when QEMU is compiled with --disable-tcg:
ERROR 1-tests/avocado/boot_linux_console.py:BootLinuxConsole.test_pp
From: Eugenio Pérez
This tree is able to look for a translated address from an IOVA address.
At first glance it is similar to util/iova-tree. However, SVQ working on
devices with limited IOVA space need more capabilities, like allocating
IOVA chunks or performing reverse translations (qemu addre
On a real system with POWER{8,9,10} processors, PHBs are sub-units of
the processor, they can be deactivated by firmware but not plugged in
or out like a PCI adapter on a slot. Nevertheless, having user-created
PHBs in QEMU seemed to be a good idea for testing purposes :
1. having a limited set o
s/pull-ppc-20220314
for you to fetch changes up to 9c10d86fee11d96274ea6f7cda12d2471abe3c47:
ppc/pnv: Remove user-created PHB{3,4,5} devices (2022-03-14 15:57:17 +0100)
ppc-7.0 queue :
* Removal of user-created PHB devices
* Avo
From: Frederic Barrat
Always create the PECs (PCI Express Controller) for the system. The
PECs host the PHBs and we try to find the matching PEC when creating a
PHB, so it must exist. It also matches what we do on POWER9
Fixes: 623575e16cd5 ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge"
From: Daniel Henrique Barboza
This tests times out in an IBM POWER host when compiled with
--disable-tcg.
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20220310183011.110391-7-danielhb...@gmail.com>
Signed-off-by: Cédric Le Goater
---
tests/avocado/ppc_bamboo.py | 2 ++
1 file changed,
From: Leandro Lupori
Fix Instruction Storage Interrupt (ISI) fault cause for Radix MMU,
when caused by missing PAGE_EXEC permission, to be
SRR1_NOEXEC_GUARD instead of DSISR_PROTFAULT.
This matches POWER9 hardware behavior.
Fixes: d5fee0bbe68 ("target/ppc: Implement ISA V3.00 radix page fault ha
From: Daniel Henrique Barboza
This test breaks when run in an IBM POWER host with a QEMU compiled
with --disable-tcg and the ppc-softmmu target in a similar manner as
test_ppc_g3beige did.
There's also an observation made about kvm_pr in the error message:
Command: ./qemu-system-ppc -display no
From: Daniel Henrique Barboza
This test breaks when run in an IBM POWER host with a QEMU compiled
with --disable-tcg and the ppc-softmmu target.
One thing to note is that the error message explictly mentions kvm_pr
support:
Command: ./qemu-system-ppc -display none -vga none (...)
-machine g3bei
From: Daniel Henrique Barboza
Running this test without TCG support in an IBM POWER server results
in the following error:
Command: ./qemu-system-ppc -display none -vga none (...)
-machine ref405ep (...)
Output: qemu-system-ppc: Register sync failed... If you're using
kvm-hv.ko,
From: Daniel Henrique Barboza
The icount framework relies on TCG availability. If QEMU is built with
--disable-tcg we won't have icount either, and then this test will fail
with the following message in an IBM POWER9 host:
tests/avocado/replay_kernel.py:ReplayKernelNormal.test_ppc64_pseries:
ERR
From: Daniel Henrique Barboza
This tests times out in an IBM POWER host when compiled with
--disable-tcg.
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20220310183011.110391-8-danielhb...@gmail.com>
Signed-off-by: Cédric Le Goater
---
tests/avocado/ppc_mpc8544ds.py | 2 ++
1 file change
From: Daniel Henrique Barboza
Some ppc64 hosts (e.g. IBM POWER hosts) aren't able to run the e500
machine using KVM accel. Skip this test if TCG accel isn't available.
Cc: Cleber Rosa
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Cédric Le Goater
Message-Id: <20220303153517.168943-5-dan
From: Daniel Henrique Barboza
Running this test gives us a deprecation warning telling that this
machine type is no longer supported:
Output: qemu-system-ppc: Machine type 'taihu' is deprecated:
incomplete, use 'ref405ep' instead
Moreover, this test fails to pass running in an IBM POWER
From: Daniel Henrique Barboza
All tests in the file times out when running in an IBM POWER host and
--disable-tcg with an error like the following:
Command: ./qemu-system-ppc -display none -vga none (...)
-machine 40p (...)
Output: qemu-system-ppc: Register sync failed... If you'
301 - 334 of 334 matches
Mail list logo
