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
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:
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'
MIPS CPU INT0, which is interrupt 2. */
-mipsnet_init(0x4200, env->irq[2], _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
-by: 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
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), _fatal);
Reviewed-by: Thomas Huth
ort("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
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
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,
+
fail(_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
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?
and 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
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
v_realize_and_unref(dev, bus, _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 perspective. Before
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
---
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-
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
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 | 14
:
- 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 hosts
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/about
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
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-ci.d
, 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-by: T
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
.
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/about
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/about
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 | 14
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 binary
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-by: T
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
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 d3a31a2112
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-system
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
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/.gitlab
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/docs
.
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 +45,16
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.yml b
, 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 file c
,
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/docs
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 CI
Thomas
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 runners
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
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
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-system
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-system-arm
.
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: Thomas Huth
%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..cc3a39d21a
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.
Signed-off-by: Thomas Huth
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:
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
/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
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
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
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
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
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
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
The define is only used in one other place. Move the code there
instead of keeping this xen-specific define in sysemu.h.
Signed-off-by: Thomas Huth
---
hw/xenpv/xen_machine_pv.c | 2 +-
include/sysemu/sysemu.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/xenpv
emory */
> };
>
> static void host_pci_config_read(int pos, int len, uint32_t *val, Error
> **errp)
>
Reviewed-by: Thomas Huth
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
nfos);
> -for (i = 0; i < num; i++) {
> +for (i = 0; i < ARRAY_SIZE(igd_host_bridge_infos); i++) {
> pos = igd_host_bridge_infos[i].offset;
> len = igd_host_bridge_infos[i].len;
> host_pci_config_read(pos, len, , _err);
>
Reviewed-
e Mathieu-Daudé
> ---
> include/hw/pci-host/i440fx.h | 19 +--
> hw/pci-host/i440fx.c | 18 --
> 2 files changed, 17 insertions(+), 20 deletions(-)
Reviewed-by: Thomas Huth
___
Xen-d
Bridge Emulation
> *
> * Copyright (c) 2006 Fabrice Bellard
> *
>
Reviewed-by: Thomas Huth
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ude/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -172,8 +172,6 @@ typedef struct GSIState {
> qemu_irq ioapic_irq[IOAPIC_NUM_PINS];
> } GSIState;
>
> -void gsi_handler(void *opaque, int n, int level);
> -
> GSIState *p
On 17/10/2019 17.31, Philippe Mathieu-Daudé wrote:
> On 10/17/19 5:04 PM, Thomas Huth wrote:
>> On 15/10/2019 18.26, Philippe Mathieu-Daudé wrote:
>>> Move the KVM-related call to "sysemu/kvm.h".
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé
>>
w/i386/pc_q35.c | 9 +
> include/hw/i386/pc.h | 2 ++
> 4 files changed, 19 insertions(+), 16 deletions(-)
Is this really needed for this series here, or should this and the
following patches maybe rather be handled seperately?
Anyway, it looks like a good modification
On 15/10/2019 18.26, Philippe Mathieu-Daudé wrote:
>
> Remove i8257 instanciated in malta board, to not have it twice.
s/instanciated/instantiated/
Thomas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
---
> include/hw/irq.h | 5 -
> 2 files changed, 19 deletions(-)
>
Reviewed-by: Thomas Huth
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 15/10/2019 18.26, Philippe Mathieu-Daudé wrote:
> From: Hervé Poussineau
>
> PIIX4 structure is now 's'
> PCI device is now 'pci_dev'
> DeviceState is now 'dev'
Why? Just for the sake of it?
> Acked-by: Michael S. Tsirkin
> Acked-by: Paolo Bonzini
> Signed-off-by: Hervé Poussineau
>
1 - 100 of 111 matches
Mail list logo
