pe = g_strdup_printf("%s%s", accel_name, ACCEL_CLASS_SUFFIX);
+
+return qtest_qom_has_concrete_type("accel", accel_type, &list);
}
Nice!
Reviewed-by: Thomas Huth
, 51 insertions(+), 38 deletions(-)
Reviewed-by: Thomas Huth
ts/device-crash-test| 2 +-
8 files changed, 10 insertions(+), 9 deletions(-)
Reviewed-by: Thomas Huth
/oss-fuzz/reorder_fuzzer_qtest_trace.py | 6 +++---
5 files changed, 6 insertions(+), 8 deletions(-)
Reviewed-by: Thomas Huth
On 03/12/2024 10.21, Philippe Mathieu-Daudé wrote:
Since commit 6f6e1698a68 ("vl: configure accelerators from -accel
options") we prefer the '-accel bar' command line option.
Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in
functional tests.
Signed-off-by: Philippe Mathieu-Daudé
pseries,x-vof=on,accel=kvm '
+ '-accel kvm '
+ '-machine pseries,x-vof=on '
'-machine cap-cfpc=broken,cap-sbbc=broken,'
'cap-ibs=broken,cap-ccf-assist=off '
'-drive file=/dev/nvme0n1,format=raw,readonly=on '
Reviewed-by: Thomas Huth
Am Wed, 6 Nov 2024 18:46:11 +
schrieb Philippe Mathieu-Daudé :
> These devices are only used by the OpenRISC target, which is
> only built as big-endian. Therefore the DEVICE_NATIVE_ENDIAN
> definition expand to DEVICE_BIG_ENDIAN (besides, the
> DEVICE_LITTLE_ENDIAN case isn't tested). Simpli
xen/xen_platform.c | 2 +-
> 5 files changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Thomas Huth
isn't tested). Simplify directly using
> DEVICE_LITTLE_ENDIAN.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/tricore/tricore_testdevice.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Thomas Huth
tested). Simplify directly
> using DEVICE_BIG_ENDIAN.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/m68k/mcf5206.c | 2 +-
> hw/m68k/mcf5208.c | 6 +++---
> hw/m68k/mcf_intc.c | 2 +-
> hw/m68k/next-kbd.c | 2 +-
> 4 files changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Thomas Huth
oid xen_config_cleanup(void);
int xen_config_dev_vfb(int vdev, const char *type);
int xen_config_dev_vkbd(int vdev);
-int xen_config_dev_console(int vdev);
#endif /* HW_XEN_LEGACY_BACKEND_H */
Reviewed-by: Thomas Huth
On 24/04/2024 12.41, Prasad Pandit wrote:
On Wednesday, 24 April, 2024 at 03:36:01 pm IST, Philippe Mathieu-Daudé wrote:
On 1/6/23 05:18, Akihiko Odaki wrote:
Recently MemReentrancyGuard was added to DeviceState to record that the
device is engaging in I/O. The network device backend needs to u
On 30/01/2024 14.01, Igor Mammedov wrote:
On Mon, 29 Jan 2024 17:44:56 +0100
Philippe Mathieu-Daudé wrote:
Mechanical patch produced running the command documented
in scripts/coccinelle/cpu_env.cocci_template header.
commenting here since, I'm not expert on coccinelle scripts.
On negative
On 26/01/2024 18.25, David Woodhouse wrote:
From: David Woodhouse
When converting to the shiny build-system-du-jour, a typo prevented the
last_i82596 driver from being built. Correct the config option name to
re-enable the build. And include "sysemu/sysemu.h" so it actually builds.
Fixes: b141
On 25/01/2024 17.56, Philippe Mathieu-Daudé wrote:
Mechanical patch produced running the command documented
in scripts/coccinelle/cpu_env.cocci_template header.
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/hvf/vmx.h | 9 +++
hw/i386/vmmouse.c
On 08/01/2024 21.27, David Woodhouse wrote:
From: David Woodhouse
These old functions can be removed now too. Let net_param_nic() print
the full set of network devices directly, and also make it note that a
list more specific to this platform/config will be available by using
'-nic model=help'
t uses the MIPS CPU INT0, which is interrupt 2. */
-mipsnet_init(0x4200, env->irq[2], &nd_table[0]);
+/* MIPSnet uses the MIPS CPU INT0, which is interrupt 2. */
+mipsnet_init(0x4200, env->irq[2]);
}
static void mips_mipssim_machine_init(MachineClass *mc)
Reviewed-by: Thomas Huth
On 08/01/2024 21.27, David Woodhouse wrote:
From: David Woodhouse
Please add: "Also remove the leftover definition of host_net_devices which
has been forgotten to be removed in commit 7cc28cb061040cb089." (or so)
With that:
Reviewed-by: Thomas Huth
Signed-off-by: David
: Thomas Huth
On 08/01/2024 21.27, David Woodhouse wrote:
From: David Woodhouse
Please add a short patch description à la "All callers have been converted
in the previous patches, so this is not required anymore".
With that:
Reviewed-by: Thomas Huth
Signed-off-by: David Woodhouse
---
i
, true, NULL);
qdev_prop_set_uint32(dev, "tx-ping-pong", 0);
qdev_prop_set_uint32(dev, "rx-ping-pong", 0);
sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
Reviewed-by: Thomas Huth
> 1) {
-error_report("Too many NICs");
-exit(1);
-}
I wonder whether we'd need a different mechanism to specify the maximum
amount of on-board NICs now... Anyway, we can also think of that later, so:
Reviewed-by: Thomas Huth
e
actually want more).
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
include/net/net.h | 3 +++
net/net.c | 53 +++
2 files changed, 56 insertions(+)
Reviewed-by: Thomas Huth
On 26/01/2024 15.34, David Woodhouse wrote:
On Fri, 2024-01-26 at 15:24 +0100, Thomas Huth wrote:
On 26/01/2024 15.16, David Woodhouse wrote:
On Fri, 2024-01-26 at 12:10 +0100, Thomas Huth wrote:
+/* "Please create a device, if you have a configuration for it" */
+D
On 08/01/2024 21.26, David Woodhouse wrote:
From: David Woodhouse
By noting the models for which a configuration was requested, we can give
the user an accurate list of which NIC models were actually available on
the platform/configuration that was otherwise chosen.
Signed-off-by: David Woodho
On 26/01/2024 15.16, David Woodhouse wrote:
On Fri, 2024-01-26 at 12:10 +0100, Thomas Huth wrote:
+/* "Please create a device, if you have a configuration for it" */
+DeviceState *qemu_create_nic_device(const char *typename, bool match_default,
+
l(&nd_table[i], pci_bus, mc->default_nic, NULL);
-}
+pci_init_nic_devices(pci_bus, mc->default_nic);
}
static void mips_loongson3_virt_init(MachineState *machine)
Reviewed-by: Thomas Huth
ail(nd, pci_bus, "pcnet", default_devaddr);
-}
+/* The malta board has a PCNet card using PCI SLOT 11 */
+pci_init_nic_in_slot(pci_bus, "pcnet", NULL, "0b");
+ pci_init_nic_devices(pci_bus, "pcnet");
}
Reviewed-by: Thomas Huth
Philippe, could you maybe have a look at this, too?
the rest
will be dynamically assigned.
Sounds fine for me ... Philippe, what do you think?
Reviewed-by: Thomas Huth
Signed-off-by: David Woodhouse
---
hw/mips/fuloong2e.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/hw/mips/fuloong2e.c b/hw/mips
On 26/01/2024 12.25, David Woodhouse wrote:
On Fri, 2024-01-26 at 12:20 +0100, Thomas Huth wrote:
On 26/01/2024 12.13, David Woodhouse wrote:
On Fri, 2024-01-26 at 11:43 +0100, Thomas Huth wrote:
On 08/01/2024 21.26, David Woodhouse wrote:
From: David Woodhouse
Eliminate direct access to
On 26/01/2024 12.13, David Woodhouse wrote:
On Fri, 2024-01-26 at 11:43 +0100, Thomas Huth wrote:
On 08/01/2024 21.26, David Woodhouse wrote:
From: David Woodhouse
Eliminate direct access to nd_table[] and nb_nics by processing the the
Xen and ISA NICs first and then calling
On 08/01/2024 21.26, David Woodhouse wrote:
From: David Woodhouse
Most code which directly accesses nd_table[] and nb_nics uses them for
one of two things. Either "I have created a NIC device and I'd like a
configuration for it", or "I will create a NIC device *if* there is a
configuration for
On 08/01/2024 21.26, David Woodhouse wrote:
From: David Woodhouse
Eliminate direct access to nd_table[] and nb_nics by processing the the
Xen and ISA NICs first and then calling pci_init_nic_devices() for the
rest.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/pc.c
qdev_realize_and_unref(dev, bus, &error_fatal);
}
}
Acked-by: Thomas Huth
On 10/11/2023 10.30, Jan Beulich wrote:
On 09.11.2023 18:40, Thomas Huth wrote:
--- a/include/hw/xen/interface/hvm/params.h
+++ b/include/hw/xen/interface/hvm/params.h
@@ -255,7 +255,7 @@
* Note that 'mixed' mode has not been evaluated for safety from a
* security perspectiv
Let's improve the wording here.
Signed-off-by: Thomas Huth
---
include/hw/xen/interface/hvm/params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/xen/interface/hvm/params.h
b/include/hw/xen/interface/hvm/params.h
index a22b4ed45d..9bcb40284c 100644
On 11/04/2023 23.04, Vikram Garhwal wrote:
Xen is supported for aarch64 via xenpvh machine. disable-tcg option fails the
build for aarch64 target.
Link for xen on arm patch series:
https://mail.gnu.org/archive/html/qemu-devel/2023-02/msg03979.html
Signed-off-by: Vikram Garhwal
---
.gitlab-c
On 13/03/2023 09.24, Alexander Bulekov wrote:
This protects devices from bh->mmio reentrancy issues.
Thanks: Thomas Huth for diagnosing OS X test failure.
Reviewed-by: Darren Kenny
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Paul Durrant
Signed-off
On 05/02/2023 05.07, Alexander Bulekov wrote:
This protects devices from bh->mmio reentrancy issues.
Reviewed-by: Darren Kenny
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Alexander Bulekov
---
...
diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 65c4979c3c..f077c1b255
On 06/03/2023 15.06, Daniel P. Berrangé wrote:
On Mon, Mar 06, 2023 at 02:48:16PM +0100, Thomas Huth wrote:
On 06/03/2023 10.27, Daniel P. Berrangé wrote:
On Mon, Mar 06, 2023 at 09:46:55AM +0100, Thomas Huth wrote:
[...] If a 32-bit CPU guest
+environment should be enforced, you can switch
On 06/03/2023 10.27, Daniel P. Berrangé wrote:
On Mon, Mar 06, 2023 at 09:46:55AM +0100, Thomas Huth wrote:
[...] If a 32-bit CPU guest
+environment should be enforced, you can switch off the "long mode" CPU
+flag, e.g. with ``-cpu max,lm=off``.
I had the idea to check this today a
On 06/03/2023 10.27, Daniel P. Berrangé wrote:
On Mon, Mar 06, 2023 at 09:46:55AM +0100, Thomas Huth wrote:
Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
binary is a proper superset of the qemu-system-i386 binary. With the
32-bit host support being deprecated, it is now
Hardly anybody still uses 32-bit arm environments for running QEMU,
so let's stop wasting our scarce CI minutes with these jobs.
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Wilfred Mallawa
Signed-off-by: Thomas Huth
---
.gitlab-ci.d/crossbuilds.yml
x86_64
v3:
- Update some commit descriptions according to the suggestions in v2
- Added the Reviewed-bys from v2
v2:
- Split binary and host deprecation into separate patches
- Added patches to immediately drop the jobs from the CI
Thomas Huth (5):
docs/about/deprecated: Deprecate 32-bit x86
e the 32-bit arm hosts here to finally save use
some time and precious CI minutes.
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Wilfred Mallawa
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/
kernel,
the developers confirmed that they do not need a recent
qemu-system-i386 binary here:
https://lore.kernel.org/kvm/y%2ffkts5ajfy0h...@google.com/
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Wilfred Mallawa
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 14 ++
1
rangé
Reviewed-by: Wilfred Mallawa
Signed-off-by: Thomas Huth
---
.gitlab-ci.d/crossbuilds.yml | 10 --
1 file changed, 10 deletions(-)
diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml
index d3a31a2112..a25cb87ae4 100644
--- a/.gitlab-ci.d/crossbuilds.yml
+++ b/.gitlab
, which is "perhaps worse than not working at all"
(quoting Richard). Let's simply make it clear that people should use
64-bit x86 hosts nowadays and we do not intend to fix/maintain the old
32-bit stuff.
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Wilfred Mallawa
Signed-off-
On 03/03/2023 12.16, Peter Maydell wrote:
On Thu, 2 Mar 2023 at 16:31, Thomas Huth wrote:
qemu-system-aarch64 is a proper superset of qemu-system-arm,
and the latter was mainly still required for 32-bit KVM support.
But this 32-bit KVM arm support has been dropped in the Linux
kernel a couple
On 03/03/2023 12.09, John Paul Adrian Glaubitz wrote:
Hello!
On Fri, 2023-03-03 at 10:48 +0100, Thomas Huth wrote:
x86 ==> deprecate both, user and system emulation support on
32-bit hosts
arm ==> deprecate only system emulation on 32-bit hosts.
I would recommend against dr
t now.
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Wilfred Mallawa
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 10 ++
1 file changed, 10 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index e2e908f84d..1b7b3da309 100644
--- a/docs/
e the 32-bit arm hosts here to finally save use
some time and precious CI minutes.
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Wilfred Mallawa
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/
Hardly anybody still uses 32-bit arm environments for running QEMU,
so let's stop wasting our scarce CI minutes with these jobs.
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Wilfred Mallawa
Signed-off-by: Thomas Huth
---
.gitlab-ci.d/crossbuilds.yml
estions in v2
- Added the Reviewed-bys from v2
v2:
- Split binary and host deprecation into separate patches
- Added patches to immediately drop the jobs from the CI
Thomas Huth (6):
docs/about/deprecated: Deprecate 32-bit x86 hosts
docs/about/deprecated: Deprecate the qemu-system-i386 binar
, which is "perhaps worse than not working at all"
(quoting Richard). Let's simply make it clear that people should use
64-bit x86 hosts nowadays and we do not intend to fix/maintain the old
32-bit stuff.
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Wilfred Mallawa
Signed-off-
kernel,
the developers confirmed that they do not need a recent
qemu-system-i386 binary here:
https://lore.kernel.org/kvm/y%2ffkts5ajfy0h...@google.com/
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Wilfred Mallawa
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 12
1
uce a flaw locally)
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Wilfred Mallawa
Signed-off-by: Thomas Huth
---
.gitlab-ci.d/crossbuilds.yml | 20
1 file changed, 20 deletions(-)
diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml
index d3a31
On 02/03/2023 23.07, Philippe Mathieu-Daudé wrote:
On 2/3/23 17:31, Thomas Huth wrote:
We're struggling quite badly with our CI minutes on the shared
gitlab runners, so we urgently need to think of ways to cut down
our supported build and target environments. qemu-system-i386 and
qemu-s
On 02/03/2023 23.16, Philippe Mathieu-Daudé wrote:
On 2/3/23 17:31, Thomas Huth wrote:
qemu-system-aarch64 is a proper superset of qemu-system-arm,
and the latter was mainly still required for 32-bit KVM support.
But this 32-bit KVM arm support has been dropped in the Linux
kernel a couple of
Hardly anybody still uses 32-bit arm environments for running QEMU,
so let's stop wasting our scarce CI minutes with these jobs.
Signed-off-by: Thomas Huth
---
.gitlab-ci.d/crossbuilds.yml | 14 --
1 file changed, 14 deletions(-)
diff --git a/.gitlab-ci.d/crossbuilds.yml b/.g
e the 32-bit arm hosts here to finally save use
some time and precious CI minutes.
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 21ce70b5c9..c7113a7510 100644
--- a
t now.
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 10 ++
1 file changed, 10 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index a30aa8dfdf..21ce70b5c9 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -45,6 +
Hardly anybody still uses 32-bit x86 environments for running QEMU,
so let's stop wasting our scarce CI minutes with these jobs.
Signed-off-by: Thomas Huth
---
.gitlab-ci.d/crossbuilds.yml | 16
1 file changed, 16 deletions(-)
diff --git a/.gitlab-ci.d/crossbuilds.
, which is "perhaps worse than not working at all"
(quoting Richard). Let's simply make it clear that people should use
64-bit x86 hosts nowadays and we do not intend to fix/maintain the old
32-bit stuff.
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 12
1 f
,
the developers confirmed that they do not need a recent
qemu-system-i386 binary here:
https://lore.kernel.org/kvm/y%2ffkts5ajfy0h...@google.com/
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 12
1 file changed, 12 insertions(+)
diff --git a/docs/about/deprecated.rst b
if we drop these host
environments soon (these are also the two architectures that contribute
the most to the long test times in our CI, so we would benefit a lot by
dropping those).
v2:
- Split binary and host deprecation into separate patches
- Added patches to immediately drop the jobs from the
On 28/02/2023 22.32, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 09:05:16PM +0100, Thomas Huth wrote:
Well, without CI, I assume that the code will bitrot quite fast (considering
that there are continuous improvements to TCG, for example).
We have lots of hosts which we don't test
On 28/02/2023 10.01, Daniel P. Berrangé wrote:
On Tue, Feb 28, 2023 at 08:39:49AM +0100, Thomas Huth wrote:
On 27/02/2023 19.38, Daniel P. Berrangé wrote:
On Mon, Feb 27, 2023 at 12:10:48PM +0100, Thomas Huth wrote:
We're struggling quite badly with our CI minutes on the shared
gitlab ru
On 28/02/2023 11.51, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
The question to answer: Is 32 bit x86 worth its upkeep? Two
sub-questions: 1. Is it worth the human attention? 2. Is it worth
(scarce!) CI minutes?
3. Is it worth arguing about?
On 28/02/2023 10.03, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 08:59:52AM +, Daniel P. Berrangé wrote:
On Tue, Feb 28, 2023 at 03:19:20AM -0500, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 08:49:09AM +0100, Thomas Huth wrote:
On 27/02/2023 21.12, Michael S. Tsirkin wrote
On 27/02/2023 21.25, Richard Henderson wrote:
On 2/27/23 01:50, Daniel P. Berrangé wrote:
On Mon, Feb 27, 2023 at 12:10:49PM +0100, Thomas Huth wrote:
Hardly anybody still uses 32-bit x86 hosts today, so we should
start deprecating them to finally have less test efforts.
With regards to 32-bit
On 27/02/2023 21.12, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
I feel like we should have separate deprecation entries for the
i686 host support, and for qemu-system-i386 emulator binary, as
although they're related they are independant feature
On 27/02/2023 23.32, Philippe Mathieu-Daudé wrote:
On 27/2/23 21:12, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
I feel like we should have separate deprecation entries for the
i686 host support, and for qemu-system-i386 emulator binary, as
alth
On 27/02/2023 19.38, Daniel P. Berrangé wrote:
On Mon, Feb 27, 2023 at 12:10:48PM +0100, Thomas Huth wrote:
We're struggling quite badly with our CI minutes on the shared
gitlab runners, so we urgently need to think of ways to cut down
our supported build and target environments. qemu-s
these host environments
now (these are also the two architectures that contribute the most to
the long test times in our CI, so we would benefit a lot by dropping
those).
Thomas Huth (2):
docs/about: Deprecate 32-bit x86 hosts and qemu-system-i386
docs/about: Deprecate 32-bit arm hosts and qemu-
t now.
Additionally, it's quite unlikely that anybody is still running
full system emulation on a 32-bit arm host nowadays. All recent
strong arm host machines should support 64-bit now, so we also
deprecate the 32-bit hosts here to finally save some precious
minutes in our CI.
Signed-off-by: T
%2ffkts5ajfy0h...@google.com/
Signed-off-by: Thomas Huth
---
docs/about/deprecated.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 15084f7bea..98517f5187 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about
On 19/12/2022 14.02, Daniel P. Berrangé wrote:
Signed-off-by: Daniel P. Berrangé
---
tests/qtest/ahci-test.c | 3 +++
tests/qtest/arm-cpu-features.c| 1 +
tests/qtest/erst-test.c | 2 +-
tests/qtest/ide-test.c| 3 ++-
tests/qtest/ivshmem-test.c
,
const char *src, int line, const char *func,
ErrorClass err_class, const char *fmt, va_list ap,
Reviewed-by: Thomas Huth
The Xen hypervisor is only available on x86 and arm - thus let's
limit the related options to these targets.
Signed-off-by: Thomas Huth
---
qemu-options.hx | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 1764eebfaf..cc3a3
stem-sparc -vga help
none no graphic card
xenfbXen paravirtualized framebuffer
tcx TCX framebuffer (default)
cg3 CG3 framebuffer
Let's avoid this situation by fencing the parameter with the
CONFIG_XEN_BACKEND switch.
S
On 16/03/2022 14.16, Philippe Mathieu-Daudé wrote:
On 16/3/22 10:52, marcandre.lur...@redhat.com wrote:
From: Marc-André Lureau
One less qemu-specific macro. It also helps to make some headers/units
only depend on glib, and thus moved in standalone projects eventually.
Signed-off-by: Marc-And
EN_PUBLIC_IO_USBIF_H
#include "ring.h"
#include "../grant_table.h"
I hope the Xen people can comment on whether the underscores had a purpose
here or whether it's ok to remove them, thus:
Cc: xen-devel@lists.xenproject.org
From my QEMU-developer's side of view:
Reviewed-by: Thomas Huth
cel_build_job
> + variables:
> +IMAGE: debian-arm64-cross
> + ACCEL: xen
> +ACCEL_CONFIGURE_OPTS: --disable-tcg --disable-kvm
Reviewed-by: Thomas Huth
On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote:
> Cross-build ARM and X86 targets with only Xen accelerator enabled.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> .gitlab-ci.d/crossbuilds.yml | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/.gitlab-ci.d/crossbuil
/qemu/$IMAGE:latest
> @@ -120,6 +119,13 @@ cross-s390x-user:
>variables:
> IMAGE: debian-s390x-cross
>
> +cross-s390x-kvm:
I'd still prefer "-no-tcg" or maybe "-kvm-only" ... but that's just a matter
of taste, so:
Reviewed-by: Thomas Huth
job - e.g.
by adding a $EXTRA_CONFIGURE_OPTS variable in the "../configure ..." line so
that the accel-jobs could use that for their --enable... and --disable...
settings?
Anyway, I've got no strong opinion on that one, and I'm also fine if we add
this new template, so:
Reviewed-by: Thomas Huth
eing the single accelerator
> +# available.
> build-tcg-disabled:
> <<: *native_build_job_definition
>variables:
>
Reviewed-by: Thomas Huth
On 07/12/2020 11.26, Philippe Mathieu-Daudé wrote:
> On 12/7/20 11:00 AM, Philippe Mathieu-Daudé wrote:
>> On 12/7/20 6:46 AM, Thomas Huth wrote:
>>> On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote:
>>>> Cross-build s390x target with only KVM accelerator en
On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote:
> Cross-build mips target with KVM and TCG accelerators enabled.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> later we'll build KVM-only.
> ---
> .gitlab-ci.d/crossbuilds-kvm-mips.yml | 5 +
> .gitlab-ci.yml| 1 +
On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote:
> Cross-build PPC target with KVM and TCG accelerators enabled.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> later this job build KVM-only.
> ---
> .gitlab-ci.d/crossbuilds-kvm-ppc.yml | 5 +
> .gitlab-ci.yml | 1 +
On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote:
> Cross-build s390x target with only KVM accelerator enabled.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> .gitlab-ci.d/crossbuilds-kvm-s390x.yml | 6 ++
> .gitlab-ci.yml | 1 +
> MAINTAINERS
On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote:
> Cross-build ARM aarch64 target with KVM and TCG accelerators enabled.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> later this job will build KVM-only.
> ---
> .gitlab-ci.d/crossbuilds-kvm-arm.yml | 5 +
> .gitlab-ci.yml
On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote:
> Cross-build x86 target with only KVM accelerator enabled.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> .gitlab-ci.d/crossbuilds-kvm-x86.yml | 6 ++
> .gitlab-ci.yml | 1 +
> MAINTAINERS |
by: Wainer dos Santos Moschetta
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> .gitlab-ci.d/crossbuilds.yml | 40 ++--
> 1 file changed, 20 insertions(+), 20 deletions(-)
Reviewed-by: Thomas Huth
On 04/11/2020 03.27, Stefano Stabellini wrote:
[...]
> Actually I care about Xen and 9pfs support, it is one of the few
> combinations that I use regularly and it is even enabled in the Xilinx
> product I look after. But admittedly I don't test QEMU master as much as
> I should. With the recent cha
On 30/10/2020 18.13, Paolo Bonzini wrote:
> On 30/10/20 12:35, Eduardo Habkost wrote:
>>
>> What is necessary to make sure we have a CONFIG_XEN=y job in
>> gitlab CI? Maybe just including xen-devel in some of the
>> container images is enough?
>
> Fedora already has it, but build-system-fedora do
On 22/10/2020 17.29, Paolo Bonzini wrote:
> On 22/10/20 17:17, Jason Andryuk wrote:
>> On Tue, Oct 13, 2020 at 1:16 PM Paolo Bonzini wrote:
>>>
>>> On 13/10/20 16:05, Jason Andryuk wrote:
Xen was left behind when CpusAccel became mandatory and fails the assert
in qemu_init_vcpu(). It re
UPPERCASE);
>
> Signed-off-by: Eduardo Habkost
> ---
Acked-by: Thomas Huth
Am Mon, 8 Jun 2020 18:00:31 +0200
schrieb Philippe Mathieu-Daudé :
> This code hasn't been QOM'ified yet. Warn the user.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/m68k/mcf5206.c | 5 +
> hw/m68k/mcf5208.c | 3 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/hw/m68k/mcf5
1 - 100 of 122 matches
Mail list logo
