On 2018-12-18 17:11, Thomas Huth wrote:
> The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
> It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
> is derived from XenDevice which in turn is derived from DeviceState
> since commit 3a6c9172ac5951e ("
On 2019-01-22 15:46, Kevin Wolf wrote:
> Am 22.01.2019 um 15:19 hat Thomas Huth geschrieben:
>> On 2018-12-18 17:11, Thomas Huth wrote:
>>> The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
>>> It passes a pointer to a XenBlkDev as second parameter. Xe
On 8/16/19 9:37 AM, tony.ngu...@bt.com wrote:
> Simplify endianness comparisons with consistent use of the more
> expressive MemOp.
>
> Suggested-by: Richard Henderson
> Signed-off-by: Tony Nguyen
> Reviewed-by: Richard Henderson
> Acked-by: David Gibson
This patch is *huge*, more than 800kB.
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
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
-num = ARRAY_SIZE(igd_host_bridge_infos);
> -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
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
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é
> ---
> include/hw/i386/pc.h | 1 -
> include/sysemu/kvm.h | 1 +
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/hw/i386/pc.h b/
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
> Messa
> 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:
>
> Remove i8257 instanciated in malta board, to not have it twice.
s/instanciated/instantiated/
Thomas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/
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 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é
>>
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
e code can also simply use blk_attach_dev() with a pointer
to the DeviceState instead.
So we can finally remove all code related to the "legacy_dev" flag, too,
and turn the related "void *" in block-backend.c into "DeviceState *"
to fix some of the remaining TODOs there.
On 2018-12-18 19:33, Markus Armbruster wrote:
> Thomas Huth writes:
>
>> The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
>> It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
>> is derived from XenDevice which in turn is derived from Dev
is only printed if configure is run with bash. On
> systems where /bin/sh is not bash, it is necessary to say bash
> ./configure to get the extra debug info in the log.
>
> Suggested-by: Eric Blake
> Signed-off-by: Ian Jackson
> CC: Kent R. Spillner
> CC: Janosch Frank
>
)
> {
> if (chroot_dir) {
> if (chroot(chroot_dir) < 0) {
> -fprintf(stderr, "chroot failed\n");
> +error_report("chroot failed");
> exit(1);
> }
> if (chdir("
->pw_uid);
> +error_report("Failed to setuid(%d)", user_pwd->pw_uid);
> exit(1);
> }
> if (setuid(0) != -1) {
> -fprintf(stderr, "Dropping privileges failed\n");
> +error_report("Dropping privileges failed");
> exit(1);
> }
> }
>
Reviewed-by: Thomas Huth
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 20.03.2018 14:32, Gerd Hoffmann wrote:
> Hi,
>
>>> So for these, we should use "". None of these are generated files though.
>>
>> That leads to crazy inconsistent message for developers where 50% of QEMU
>> header files must use <> and the other 50% of header files must use "".
>
> The rul
On 20.03.2018 13:05, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
>> Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
>>> QEMU coding style at the moment asks for all non-system
>>> include files to be used with #include "foo.h".
>>> However this ru
UPPERCASE);
>
> Signed-off-by: Eduardo Habkost
> ---
Acked-by: Thomas Huth
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
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 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
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
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
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
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
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
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
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
%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
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
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-
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
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 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 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 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 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.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 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
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
, 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
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.
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 +
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
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
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
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
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
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
, 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-
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
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
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/
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/
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
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
, 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-
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
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
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/
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
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
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
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 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 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 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 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
,
const char *src, int line, const char *func,
ErrorClass err_class, const char *fmt, va_list ap,
Reviewed-by: Thomas Huth
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
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
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 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
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
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
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 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
qdev_realize_and_unref(dev, bus, &error_fatal);
}
}
Acked-by: Thomas Huth
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
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 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 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
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
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?
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
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,
+
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.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
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
> 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
, 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
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
: 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
1 - 100 of 122 matches
Mail list logo
