"Kim, Dongwon" writes:
> On 7/10/2023 11:36 PM, Markus Armbruster wrote:
>> "Kim, Dongwon" writes:
>>
>>> On 7/9/2023 11:05 PM, Markus Armbruster wrote:
"Kim, Dongwon" writes:
> On 7/7/2023 7:07 AM, Markus Armbruster wrote:
[...]
>> Old question not yet answered: Using a
As docs/devel/loads-stores.rst states:
``GETPC()`` should be used with great care: calling
it in other functions that are *not* the top level
``HELPER(foo)`` will cause unexpected behavior. Instead, the
value of ``GETPC()`` should be read from the helper and passed
if needed to the
As docs/devel/loads-stores.rst states:
``GETPC()`` should be used with great care: calling
it in other functions that are *not* the top level
``HELPER(foo)`` will cause unexpected behavior. Instead, the
value of ``GETPC()`` should be read from the helper and passed
if needed to the
As docs/devel/loads-stores.rst states:
``GETPC()`` should be used with great care: calling
it in other functions that are *not* the top level
``HELPER(foo)`` will cause unexpected behavior. Instead, the
value of ``GETPC()`` should be read from the helper and passed
if needed to the
On Mon Jul 10, 2023 at 10:25 AM AEST, Joel Stanley wrote:
> On Sat, 8 Jul 2023 at 01:17, Nicholas Piggin wrote:
>
> > > --- a/include/hw/ppc/pnv_xscom.h
> > > +++ b/include/hw/ppc/pnv_xscom.h
> > > @@ -127,6 +127,17 @@ struct PnvXScomInterfaceClass {
> > > #define PNV10_XSCOM_EC(proc)
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 regular packet, it
> does expect a
On Tue Jul 11, 2023 at 9:03 PM AEST, Matheus Tavares Bernardino wrote:
> > Nicholas Piggin wrote:
> >
> > diff --git a/gdbstub/gdbstub.c b/gdbstub/gdbstub.c
> > index 6911b73c07..ce8b42eb15 100644
> > --- a/gdbstub/gdbstub.c
> > +++ b/gdbstub/gdbstub.c
> > @@ -2051,8 +2051,17 @@ void
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 changed, 99 insertions(+)
>
> diff --git a/tests/qtest/migration-test.c
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 behavior observed on the POWER9 CPU.
>From the POWER9
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 insertion(+), 1 deletion(-)
diff --git a/tests/qtest/migration-test.c
On 7/11/23 16:34, Philippe Mathieu-Daudé wrote:
Since commit fbd3c4cff6 ("linux-user/arm: Mark the commpage
executable") executing bare-metal (linked with rdimon.specs)
cortex-M code fails as:
$ qemu-arm -cpu cortex-m3 ~/hello.exe.m3
qemu-arm: ../../accel/tcg/user-exec.c:492:
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
> bdrv_pad_request()'s callers
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 see:
[ 335.445922] sd 0:0:0:0: [sda]
On Tue, Jul 11, 2023 at 8:49 AM Philippe Mathieu-Daudé
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-GENERATED" comment in
> JSON, create the files under tests/vm/generated/
Am 11. Juli 2023 09:11:33 UTC schrieb Olaf Hering :
>Wed, 05 Jul 2023 21:52:05 + Bernhard Beschow :
>
>> I wonder if we should fix this line rather than dropping it.
>
>I think this needs to be fixed, just to fix the initial commit which
>added this bug. This will allow backporting this
Am 1. Juli 2023 17:46:59 UTC schrieb Olaf Hering :
>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
On Tue, Jul 11, 2023, 12:43 AM Pavel Dovgalyuk
wrote:
> On 10.07.2023 20:14, Philippe Mathieu-Daudé wrote:
> > Hi,
> >
> > Per tests/avocado/replay_kernel.py:
> >
> > def test_aarch64_virt(self):
> > ...
> > console_pattern = 'VFS: Cannot open root device'
> >
> > the test
On Tue, Jul 11, 2023 at 04:49:22PM +0200, Philippe Mathieu-Daudé wrote:
> Get an up-to-date package list from lcitool, that way we
> don't need to manually keep this array in sync.
>
> Inspired-by: Thomas Huth
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> tests/vm/freebsd | 42
On Tue, Jul 11, 2023 at 04:49:21PM +0200, Philippe Mathieu-Daudé wrote:
> Add the get_qemu_packages_from_lcitool_json() helper which return
> such package list from a lcitool env var file in JSON format.
>
> Suggested-by: Daniel P. Berrangé
> Signed-off-by: Philippe Mathieu-Daudé
> ---
>
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/dockerfiles/ubuntu2004.docker |
On 7/10/23 22:47, Eric Blake wrote:
> On Mon, Jun 26, 2023 at 07:08:33PM +0300, Andrey Drobyshev via wrote:
>> When target image is using subclusters, and we align the request during
>> copy-on-read, it makes sense to align to subcluster_size rather than
>> cluster_size. Otherwise we end up with
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 QEMU patch for the
> virtio-scsi device (details at the
v1 --> v2:
* Fixed line indentation;
* Fixed wording in a comment;
* Added R-b.
v1: https://lists.nongnu.org/archive/html/qemu-block/2023-06/msg00606.html
Andrey Drobyshev (3):
block: add subcluster_size field to BlockDriverInfo
block/io: align requests to subcluster_size
When target image is using subclusters, and we align the request during
copy-on-read, it makes sense to align to subcluster_size rather than
cluster_size. Otherwise we end up with unnecessary allocations.
This commit renames bdrv_round_to_clusters() to bdrv_round_to_subclusters()
and utilizes
This is going to be used in the subsequent commit as requests alignment
(in particular, during copy-on-read). This value only makes sense for
the formats which support subclusters (currently QCOW2 only). If this
field isn't set by driver's own bdrv_get_info() implementation, we
simply set it
Add testcase which checks that allocations during copy-on-read are
performed on the subcluster basis when subclusters are enabled in target
image.
This testcase also triggers the following assert with previous commit
not being applied, so we check that as well:
qemu-io: ../block/io.c:1236:
In commit f0a08b0913befbd we changed the type of the PC from
target_ulong to vaddr. In doing so we inadvertently dropped the
zero-padding on the PC in trace lines (the second item inside the []
in these lines). They used to look like this on AArch64, for
instance:
Trace 0: 0x7f226100
On 11/7/23 18:54, Peter Maydell wrote:
In commit f0a08b0913befbd we changed the type of the PC from
target_ulong to vaddr. In doing so we inadvertently dropped the
zero-padding on the PC in trace lines (the second item inside the []
in these lines). They used to look like this on AArch64, for
On 7/10/2023 11:36 PM, Markus Armbruster wrote:
"Kim, Dongwon" writes:
On 7/9/2023 11:05 PM, Markus Armbruster wrote:
"Kim, Dongwon" writes:
On 7/7/2023 7:07 AM, Markus Armbruster wrote:
[...]
Ignorant questions:
1. How would I plug / unplug display cables?
I am not sure if I
On 2023/7/11 11:57 AM, Max Chou wrote:
On 2023/7/11 11:15 AM, Alistair Francis wrote:
On Mon, Jul 10, 2023 at 6:37 PM Max Chou wrote:
On 2023/7/8 5:25 PM, Daniel Henrique Barboza wrote:
Hi,
This patch breaks some gitlab runners because of this:
On 7/2/23 12:53, Max Chou wrote:
From:
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 revert
commit message and BZ).
This is
On 6/26/23 18:08, Andrey Drobyshev wrote:
Add testcase which checks that allocations during copy-on-read are
performed on the subcluster basis when subclusters are enabled in target
image.
This testcase also triggers the following assert with previous commit
not being applied, so we check that
On 6/26/23 18:08, Andrey Drobyshev wrote:
When target image is using subclusters, and we align the request during
copy-on-read, it makes sense to align to subcluster_size rather than
cluster_size. Otherwise we end up with unnecessary allocations.
This commit renames bdrv_round_to_clusters() to
From: Nazar Kazakov
This commit adds support for the Zvkg vector-crypto extension, which
consists of the following instructions:
* vgmul.vv
* vghsh.vv
Translation functions are defined in
`target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in
`target/riscv/vcrypto_helper.c`.
Adds sm4_ck constant for use in sm4 cryptography across different targets.
Signed-off-by: Max Chou
Reviewed-by: Frank Chang
Signed-off-by: Max Chou
---
crypto/sm4.c | 10 ++
include/crypto/sm4.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/crypto/sm4.c
This commit adds support for the Zvksed vector-crypto extension, which
consists of the following instructions:
* vsm4k.vi
* vsm4r.[vv,vs]
Translation functions are defined in
`target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in
`target/riscv/vcrypto_helper.c`.
Signed-off-by:
Allows sharing of sm4_subword between different targets.
Signed-off-by: Max Chou
Reviewed-by: Frank Chang
Reviewed-by: Richard Henderson
Signed-off-by: Max Chou
---
include/crypto/sm4.h | 8
target/arm/tcg/crypto_helper.c | 10 ++
2 files changed, 10
From: Lawrence Hunter
This commit adds support for the Zvksh vector-crypto extension, which
consists of the following instructions:
* vsm3me.vv
* vsm3c.vi
Translation functions are defined in
`target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in
`target/riscv/vcrypto_helper.c`.
From: Kiran Ostrolenk
Move some macros out of `vector_helper` and into `vector_internals`.
This ensures they can be used by both vector and vector-crypto helpers
(latter implemented in proceeding commits).
Signed-off-by: Kiran Ostrolenk
Reviewed-by: Weiwei Li
Signed-off-by: Max Chou
---
On 7/11/23 13:47, Philippe Mathieu-Daudé wrote:
On 11/7/23 18:43, Richard Henderson wrote:
Hiya,
This breakage crept in while cross-riscv64-system was otherwise broken in
configure:
https://gitlab.com/qemu-project/qemu/-/jobs/4633277557#L4165
../target/riscv/kvm.c:209:38: error:
From: Kiran Ostrolenk
This commit adds support for the Zvknh vector-crypto extension, which
consists of the following instructions:
* vsha2ms.vv
* vsha2c[hl].vv
Translation functions are defined in
`target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in
From: Dickon Hood
This commit adds support for the Zvbb vector-crypto extension, which
consists of the following instructions:
* vrol.[vv,vx]
* vror.[vv,vx,vi]
* vbrev8.v
* vrev8.v
* vandn.[vv,vx]
* vbrev.v
* vclz.v
* vctz.v
* vcpop.v
* vwsll.[vv,vx,vi]
Translation functions are defined in
From: Nazar Kazakov
Move the checks out of `do_opiv{v,x,i}_gvec{,_shift}` functions
and into the corresponding macros. This enables the functions to be
reused in proceeding commits without check duplication.
Signed-off-by: Nazar Kazakov
Reviewed-by: Richard Henderson
Reviewed-by: Weiwei Li
From: Nazar Kazakov
This commit adds support for the Zvkned vector-crypto extension, which
consists of the following instructions:
* vaesef.[vv,vs]
* vaesdf.[vv,vs]
* vaesdm.[vv,vs]
* vaesz.vs
* vaesem.[vv,vs]
* vaeskf1.vi
* vaeskf2.vi
Translation functions are defined in
From: Lawrence Hunter
This commit adds support for the Zvbc vector-crypto extension, which
consists of the following instructions:
* vclmulh.[vx,vv]
* vclmul.[vx,vv]
Translation functions are defined in
`target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in
From: Dickon Hood
Zvbb (implemented in later commit) has a widening instruction, which
requires an extra check on the enabled extensions. Refactor
GEN_OPIVX_WIDEN_TRANS() to take a check function to avoid reimplementing
it.
Signed-off-by: Dickon Hood
Reviewed-by: Richard Henderson
From: Nazar Kazakov
Remove the redundant "vl == 0" check which is already included within the
vstart >= vl check, when vl == 0.
Signed-off-by: Nazar Kazakov
Reviewed-by: Weiwei Li
Signed-off-by: Max Chou
---
target/riscv/insn_trans/trans_rvv.c.inc | 31 +
1 file
From: Kiran Ostrolenk
Take some functions/macros out of `vector_helper` and put them in a new
module called `vector_internals`. This ensures they can be used by both
vector and vector-crypto helpers (latter implemented in proceeding
commits).
Signed-off-by: Kiran Ostrolenk
Reviewed-by: Weiwei
From: Kiran Ostrolenk
Refactor the non SEW-specific stuff out of `GEN_OPIVV_TRANS` into
function `opivv_trans` (similar to `opivi_trans`). `opivv_trans` will be
used in proceeding vector-crypto commits.
Signed-off-by: Kiran Ostrolenk
Reviewed-by: Richard Henderson
Reviewed-by: Alistair
This patchset provides an implementation for Zvbb, Zvbc, Zvkned, Zvknh,
Zvksh, Zvkg, and Zvksed of the draft RISC-V vector cryptography
extensions as per the v20230620 version of the specification(1)(168e7b4).
This is an update to the patchset submitted to qemu-devel on
Wed, 12 Jul 2023 00:31:21
On 6/26/23 18:08, Andrey Drobyshev wrote:
This is going to be used in the subsequent commit as requests alignment
(in particular, during copy-on-read). This value only makes sense for
the formats which support subclusters (currently QCOW2 only). If this
field isn't set by driver's own
In commit f0a08b0913befbd we changed the type of the PC from
target_ulong to vaddr. In doing so we inadvertently dropped the
zero-padding on the PC in trace lines (the second item inside the []
in these lines). They used to look like this on AArch64, for
instance:
Trace 0: 0x7f226100
On Tue, 11 Jul 2023 09:43:48 PDT (-0700), Richard Henderson wrote:
Hiya,
This breakage crept in while cross-riscv64-system was otherwise broken in
configure:
https://gitlab.com/qemu-project/qemu/-/jobs/4633277557#L4165
../target/riscv/kvm.c:209:38: error: ‘KVM_RISCV_ISA_EXT_ZICBOZ’
On 11/7/23 18:43, Richard Henderson wrote:
Hiya,
This breakage crept in while cross-riscv64-system was otherwise broken
in configure:
https://gitlab.com/qemu-project/qemu/-/jobs/4633277557#L4165
../target/riscv/kvm.c:209:38: error: ‘KVM_RISCV_ISA_EXT_ZICBOZ’
undeclared here (not in a
Hiya,
This breakage crept in while cross-riscv64-system was otherwise broken in
configure:
https://gitlab.com/qemu-project/qemu/-/jobs/4633277557#L4165
../target/riscv/kvm.c:209:38: error: ‘KVM_RISCV_ISA_EXT_ZICBOZ’ undeclared here (not in a
function); did you mean
On Mon, 5 Jun 2023 at 21:27, Richard Henderson
wrote:
>
> This makes TranslationBlock agnostic to the address size of the guest.
> Use vaddr for pc, since that's always a virtual address.
> Use uint64_t for cs_base, since usage varies between guests.
> index 60ca9e229e..1cf4f1fa22 100644
> ---
On Mon, 26 Jun 2023 at 16:48, Richard Henderson
wrote:
>
> From: Anton Johansson
>
> Signed-off-by: Anton Johansson
> Reviewed-by: Richard Henderson
> Message-Id: <20230621135633.1649-7-a...@rev.ng>
> Signed-off-by: Richard Henderson
> -static void log_cpu_exec(target_ulong pc, CPUState
On Mon, 26 Jun 2023 at 16:40, Richard Henderson
wrote:
>
> From: Anton Johansson
>
> Signed-off-by: Anton Johansson
> Reviewed-by: Richard Henderson
> Message-Id: <20230621135633.1649-3-a...@rev.ng>
> Signed-off-by: Richard Henderson
> ---
> @@ -634,10 +634,10 @@ void
On 7/11/23 12:06, Philippe Mathieu-Daudé wrote:
While when building on native Linux the host architecture
is reported as "riscv32" or "riscv64":
Host machine cpu family: riscv64
Host machine cpu: riscv64
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Since commit ba0e733362
On 11/7/23 17:14, Cédric Le Goater wrote:
If QEMU is built with --without-default-devices, the s390-flic-kvm
device is missing and QEMU aborts when started with the KVM accelerator.
Make sure it's available by selecting S390_FLIC_KVM in Kconfig.
Consequently, this also fixes an abort in
While when building on native Linux the host architecture
is reported as "riscv32" or "riscv64":
Host machine cpu family: riscv64
Host machine cpu: riscv64
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Since commit ba0e733362 ("configure: Merge riscv32 and riscv64
host architectures"),
The next commit is going to have vhost_vdpa_dev_start() call this, so
move it up to have the declaration where we are going to need it.
Signed-off-by: Hanna Czenczek
---
hw/virtio/vhost-vdpa.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git
The only user of vhost_user_reset_status() is vhost_dev_stop(), which
only uses it as a fall-back to stop the back-end if it does not support
SUSPEND. However, vhost-user's implementation is a no-op unless the
back-end supports SET_STATUS.
vhost-vdpa's implementation instead just calls
vhost-vdpa and vhost-user differ in how they reset the status in their
respective vhost_reset_status implementations: vhost-vdpa zeroes it,
then re-adds the S_ACKNOWLEDGE and S_DRIVER config bits. S_DRIVER_OK is
then set in vhost_vdpa_dev_start().
vhost-user in contrast just zeroes the status,
Implement SUSPEND/RESUME like vDPA does, by automatically using it in
vhost_user_dev_start(). (Though our vDPA code does not implement RESUME
yet, so there, the device is reset when it is to be resumed.)
Signed-off-by: Hanna Czenczek
---
hw/virtio/vhost-user.c | 99
Hi,
As discussed on the previous version of the virtio-fs migration series
(https://lists.nongnu.org/archive/html/qemu-devel/2023-04/msg01575.html),
we currently don’t have a good way to have a vhost-user back-end fully
cease all operations, including background operations. To work around
this,
When stopping the VM, qemu wants all devices to fully cease any
operation, too. Currently, we can only have vhost-user back-ends stop
processing vrings, but not background operations. Add the SUSPEND and
RESUME commands from vDPA, which allow the front-end (qemu) to tell
back-ends to cease all
Move the `suspended` field from vhost_vdpa into the global vhost_dev
struct, so vhost_dev_stop() can check whether the back-end has been
suspended by `vhost_ops->vhost_dev_start(hdev, false)`. If it has,
there is no need to reset it; the reset is just a fall-back to stop
device operations for
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
On 11.07.23 17:37, Michael S. Tsirkin wrote:
On Tue, Jul 11, 2023 at 05:34:38PM +0200, 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
On Tue, Jul 11, 2023 at 05:34:38PM +0200, 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
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-mem devices that are
in a compatible state
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.
Tested-by: Mario Casquero
Signed-off-by: David Hildenbrand
---
hw/virtio/virtio-md-pci.c | 38 +--
Let's use our new helper functions. Note that virtio-pmem-pci is not
enabled for arm and, therefore, not compiled in.
Tested-by: Mario Casquero
Signed-off-by: David Hildenbrand
---
hw/arm/virt.c | 81 ---
1 file changed, 12 insertions(+), 69
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.,
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
Let's add a new abstract "virtio memory device" type, and use it as
parent class of virtio-mem-pci and virtio-pmem-pci.
Tested-by: Mario Casquero
Signed-off-by: David Hildenbrand
---
MAINTAINERS | 6 ++
hw/virtio/Kconfig | 8 +--
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.
Tested-by: Mario Casquero
Since commit fbd3c4cff6 ("linux-user/arm: Mark the commpage
executable") executing bare-metal (linked with rdimon.specs)
cortex-M code fails as:
$ qemu-arm -cpu cortex-m3 ~/hello.exe.m3
qemu-arm: ../../accel/tcg/user-exec.c:492: page_set_flags: Assertion `last <=
GUEST_ADDR_MAX' failed.
On 11.07.23 16:19, Mario Casquero wrote:
Tested-by: Mario Casquero
Thanks a lot Mario!
--
Cheers,
David / dhildenb
On Tue, Jul 11, 2023 at 04:49:19PM +0200, Philippe Mathieu-Daudé 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-GENERATED" comment in
> JSON, create the files under
If QEMU is built with --without-default-devices, the s390-flic-kvm
device is missing and QEMU aborts when started with the KVM accelerator.
Make sure it's available by selecting S390_FLIC_KVM in Kconfig.
Consequently, this also fixes an abort in tests/qtest/migration-test.
Signed-off-by: Cédric
On 11/7/23 16:34, Cédric Le Goater wrote:
If QEMU is built with --without-default-devices, the s390-flic-kvm
device is missing and QEMU aborts when started with the KVM accelerator.
Make sure it's available by selecting S390_FLIC_KVM in Kconfig.
Consequently, this also fixes an abort in
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-GENERATED" comment in
JSON, create the files under tests/vm/generated/ sub-directory;
add a README mentioning the files are generated.
Get an up-to-date package list from lcitool, that way we
don't need to manually keep this array in sync.
Inspired-by: Thomas Huth
Signed-off-by: Philippe Mathieu-Daudé
---
tests/vm/freebsd | 42 ++
1 file changed, 2 insertions(+), 40 deletions(-)
diff
Inspired by this patch from Thomas:
https://lore.kernel.org/qemu-devel/20230531090415.40421-1-th...@redhat.com/
Instead of updating the package list manually, use lcitool vars file.
Since v2:
- Commit generated json (Daniel)
Since v1:
- Addressed Erik & Daniel comments (generate in JSON)
Refresh the generated files by running:
$ make lcitool-refresh
Signed-off-by: Philippe Mathieu-Daudé
---
tests/docker/dockerfiles/debian-amd64.docker | 2 -
tests/docker/dockerfiles/ubuntu2004.docker | 2 -
tests/docker/dockerfiles/ubuntu2204.docker | 2 -
Add the get_qemu_packages_from_lcitool_json() helper which return
such package list from a lcitool env var file in JSON format.
Suggested-by: Daniel P. Berrangé
Signed-off-by: Philippe Mathieu-Daudé
---
tests/vm/basevm.py | 11 +++
1 file changed, 11 insertions(+)
diff --git
On 11/7/23 16:01, Philippe Mathieu-Daudé wrote:
Add the generate_pkglist() helper to generate a list of packages
required by a distribution to build QEMU.
Generate the FreeBSD JSON file (based on FreeBSD 13).
Suggested-by: Erik Skultety
Signed-off-by: Philippe Mathieu-Daudé
---
If QEMU is built with --without-default-devices, the s390-flic-kvm
device is missing and QEMU aborts when started with the KVM accelerator.
Make sure it's available by selecting S390_FLIC_KVM in Kconfig.
Consequently, this also fixes an abort in tests/qtest/migration-test.
Signed-off-by: Cédric
This series has been successfully tested by QE. Start a VM, plug a
virtio-mem device, resize the device (adding memory) and verify that
the virtio-mem device cannot be unplugged. Finally, resize the device
(removing all the memory) and check that it can be unplugged
seamlessly.
Tested-by: Mario
On 11/7/23 16:08, Daniel P. Berrangé wrote:
On Tue, Jul 11, 2023 at 04:01:42PM +0200, Philippe Mathieu-Daudé wrote:
Add the get_qemu_packages_from_lcitool_json() helper which return
such package list from a lcitool env var file in JSON format.
Suggested-by: Daniel P. Berrangé
Signed-off-by:
On Tue, Jul 11, 2023 at 04:01:42PM +0200, Philippe Mathieu-Daudé wrote:
> Add the get_qemu_packages_from_lcitool_json() helper which return
> such package list from a lcitool env var file in JSON format.
>
> Suggested-by: Daniel P. Berrangé
> Signed-off-by: Philippe Mathieu-Daudé
> ---
>
On Tue, Jul 11, 2023 at 04:01:43PM +0200, Philippe Mathieu-Daudé wrote:
> Get an up-to-date package list from lcitool, that way we
> don't need to manually keep this array in sync.
>
> Inspired-by: Thomas Huth
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> tests/vm/Makefile.include | 2 ++
>
On Tue, Jul 11, 2023 at 04:01:41PM +0200, Philippe Mathieu-Daudé wrote:
> Add the generate_pkglist() helper to generate a list of packages
> required by a distribution to build QEMU.
>
> Generate the FreeBSD JSON file (based on FreeBSD 13).
>
> Suggested-by: Erik Skultety
> Signed-off-by:
Add the get_qemu_packages_from_lcitool_json() helper which return
such package list from a lcitool env var file in JSON format.
Suggested-by: Daniel P. Berrangé
Signed-off-by: Philippe Mathieu-Daudé
---
tests/vm/Makefile.include | 4
tests/vm/basevm.py| 9 +
2 files
Get an up-to-date package list from lcitool, that way we
don't need to manually keep this array in sync.
Inspired-by: Thomas Huth
Signed-off-by: Philippe Mathieu-Daudé
---
tests/vm/Makefile.include | 2 ++
tests/vm/freebsd | 42 ++-
2 files
Inspired by this patch from Thomas:
https://lore.kernel.org/qemu-devel/20230531090415.40421-1-th...@redhat.com/
Instead of updating the package list manually, use lcitool vars file.
Since v1:
- Addressed Erik & Daniel comments (generate in JSON)
Philippe Mathieu-Daudé (3):
tests/lcitool:
Add the generate_pkglist() helper to generate a list of packages
required by a distribution to build QEMU.
Generate the FreeBSD JSON file (based on FreeBSD 13).
Suggested-by: Erik Skultety
Signed-off-by: Philippe Mathieu-Daudé
---
tests/lcitool/refresh | 11 +++
1 file changed, 11
For the vfio-ap bus driver IRQ index mapping:
Reviewed-by: Tony Krowiak
On 7/9/23 5:23 PM, Cédric Le Goater wrote:
Signed-off-by: Cédric Le Goater
---
include/standard-headers/drm/drm_fourcc.h | 43 ++
include/standard-headers/linux/const.h| 2 +-
1 - 100 of 152 matches
Mail list logo
