s not require libnl to build because the client code and
some drivers do not need libvirt to configure networking at all.
Signed-off-by: Akihiko Odaki
---
src/util/virnetdev.c | 44
src/util/virnetdevbridge.c | 29 -
() stub in
src/remote/remote_daemon.c resulted in extra debug logs.
Instead of providing stub functions, let callers check the availability
of libnl. Callers are also replaced with stub functions in most cases
so this approach requires less code and less error-prone.
Signed-off-by: Akihiko Odaki
Supersedes: <20250308-require-v1-1-fe6850bf3...@daynix.com>
("[PATCH] util: Require libnl for Linux")
Based on previous discussions, this implements yet another approach to
fix builds without libnl for Linux.
Signed-off-by: Akihiko Odaki
---
Changes in v2:
- Rebased.
- Li
Supersedes: <20250308-require-v1-1-fe6850bf3...@daynix.com>
("[PATCH] util: Require libnl for Linux")
Based on previous discussions, this implements yet another approach to
fix builds without libnl for Linux.
Signed-off-by: Akihiko Odaki
---
Akihiko Odaki (2):
Remove libnl
s not require libnl to build because the client code and
some drivers do not need libvirt to configure networking at all.
Signed-off-by: Akihiko Odaki
---
src/util/virnetdev.c | 44
src/util/virnetdevbridge.c | 33 +
() stub in
src/remote/remote_daemon.c resulted in extra debug logs.
Instead of providing stub functions, let callers check the availability
of libnl. Callers are also replaced with stub functions in most cases
so this approach requires less code and less error-prone.
Signed-off-by: Akihiko Odaki
On 2025/03/10 18:10, Peter Krempa wrote:
On Mon, Mar 10, 2025 at 09:05:28 +, Daniel P. Berrangé wrote:
On Sat, Mar 08, 2025 at 02:57:41PM +0900, Akihiko Odaki wrote:
usb-storage is a compound device that automatically creates a USB mass
storage device and a SCSI device as its backend
libnl for Linux
and let Meson direct them to install libnl.
Signed-off-by: Akihiko Odaki
---
Supersedes: <20250307-nl-v1-1-c66fc2bf8...@daynix.com>
("[PATCH] util: Check libnl function availability")
---
libvirt.spec.in | 2 -
meson.build
: Akihiko Odaki
---
Akihiko Odaki (3):
qemu_capabilities: Introduce QEMU_CAPS_DEVICE_USB_BOT
qemu: Replace usb-storage with usb-bot
qemu_capabilities: Retire QEMU_CAPS_DEVICE_USB_STORAGE
src/qemu/qemu_alias.c | 3 +-
src/qemu/qemu_capabilities.c
can be combined with a manually
created SCSI device. libvirt will configure the SCSI device in a way
identical with how QEMU does for usb-storage except that now it respects
a configuration option to represent CD-ROM.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/368
Signed-off-by: Akihiko
On 2025/03/07 22:11, Laine Stump wrote:
On 3/7/25 6:48 AM, Akihiko Odaki wrote:
virNetDevBridgeSetupVlans() calls virNetlinkBridgeVlanFilterSet(),
which requires libnl. Use the function only when libnl is available
to avoid breaking builds.
Signed-off-by: Akihiko Odaki
I'm curious wh
virNetDevBridgeSetupVlans() calls virNetlinkBridgeVlanFilterSet(),
which requires libnl. Use the function only when libnl is available
to avoid breaking builds.
Signed-off-by: Akihiko Odaki
---
src/util/virnetdevbridge.c | 122 ++---
1 file changed, 61
On 2024/08/18 16:03, Michael S. Tsirkin wrote:
On Sun, Aug 18, 2024 at 02:04:29PM +0900, Akihiko Odaki wrote:
On 2024/08/09 21:50, Fabiano Rosas wrote:
Peter Xu writes:
On Thu, Aug 08, 2024 at 10:47:28AM -0400, Michael S. Tsirkin wrote:
On Thu, Aug 08, 2024 at 10:15:36AM -0400, Peter Xu
when we don't have anything else to guard the migration.
I think neither of them is a hack; they just deal with different
scenarios summarized in [1]. We need apply a solution appropriate for
each scenario, or we will end up with a broken system.
Regards,
Akihiko Odaki
[1]
https://l
bled features. This is covered with my
-dump-platform/-merge-platform/-use-platform proposal[2].
Regards,
Akihiko Odaki
[1]
https://lore.kernel.org/r/2b62780c-a6cb-4262-beb5-81d54c14f...@daynix.com
[2]
https://lore.kernel.org/all/2da4ebcd-2058-49c3-a4ec-8e60536e5...@daynix.com/
On 2024/08/08 22:55, Peter Xu wrote:
On Thu, Aug 08, 2024 at 08:43:22PM +0900, Akihiko Odaki wrote:
On 2024/08/07 5:41, Peter Xu wrote:
On Mon, Aug 05, 2024 at 04:27:43PM +0900, Akihiko Odaki wrote:
On 2024/08/04 22:08, Peter Xu wrote:
On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki
On 2024/08/07 5:41, Peter Xu wrote:
On Mon, Aug 05, 2024 at 04:27:43PM +0900, Akihiko Odaki wrote:
On 2024/08/04 22:08, Peter Xu wrote:
On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki wrote:
On 2024/08/03 1:26, Peter Xu wrote:
On Sat, Aug 03, 2024 at 12:54:51AM +0900, Akihiko Odaki
On 2024/08/08 20:12, Michael S. Tsirkin wrote:
On Thu, Aug 08, 2024 at 08:03:25PM +0900, Akihiko Odaki wrote:
On 2024/08/08 19:54, Michael S. Tsirkin wrote:
On Thu, Aug 08, 2024 at 07:52:37PM +0900, Akihiko Odaki wrote:
On 2024/08/06 22:29, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2024 at
On 2024/08/08 19:54, Michael S. Tsirkin wrote:
On Thu, Aug 08, 2024 at 07:52:37PM +0900, Akihiko Odaki wrote:
On 2024/08/06 22:29, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2024 at 04:35:44PM +0900, Akihiko Odaki wrote:
On 2024/08/05 19:08, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2024 at
On 2024/08/06 22:29, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2024 at 04:35:44PM +0900, Akihiko Odaki wrote:
On 2024/08/05 19:08, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2024 at 06:37:58PM +0900, Akihiko Odaki wrote:
If cross-migrate=off, QEMU can still migrate on the same host (checkpoint
On 2024/08/05 19:08, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2024 at 06:37:58PM +0900, Akihiko Odaki wrote:
If cross-migrate=off, QEMU can still migrate on the same host (checkpoint
and restart). QEMU can also migrate across hosts if the user ensures they
are on the same platform.
What is
On 2024/08/05 17:23, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2024 at 04:53:52PM +0900, Akihiko Odaki wrote:
On 2024/08/05 16:30, Michael S. Tsirkin wrote:
On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki wrote:
I suggest disabling all offload features of virtio-net with 9.2.
Yea
On 2024/08/05 16:30, Michael S. Tsirkin wrote:
On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki wrote:
I suggest disabling all offload features of virtio-net with 9.2.
Yea ... no.
I want to keep things consistent so I want to disable all at once. This
change will be very
On 2024/08/04 22:08, Peter Xu wrote:
On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki wrote:
On 2024/08/03 1:26, Peter Xu wrote:
On Sat, Aug 03, 2024 at 12:54:51AM +0900, Akihiko Odaki wrote:
I'm not sure if I read it right. Perhaps you meant something more generic
than -platfor
On 2024/08/03 1:26, Peter Xu wrote:
On Sat, Aug 03, 2024 at 12:54:51AM +0900, Akihiko Odaki wrote:
I'm not sure if I read it right. Perhaps you meant something more generic
than -platform but similar?
For example, "-profile [PROFILE]" qemu cmdline, where PROFILE can be e
On 2024/08/03 0:05, Peter Xu wrote:
On Fri, Aug 02, 2024 at 01:30:51PM +0900, Akihiko Odaki wrote:
On 2024/08/02 0:13, Peter Xu wrote:
On Thu, Aug 01, 2024 at 02:05:54PM +0900, Akihiko Odaki wrote:
On 2024/07/31 4:11, Peter Xu wrote:
On Tue, Jul 30, 2024 at 07:46:12PM +0100, Daniel P
On 2024/08/02 0:13, Peter Xu wrote:
On Thu, Aug 01, 2024 at 02:05:54PM +0900, Akihiko Odaki wrote:
On 2024/07/31 4:11, Peter Xu wrote:
On Tue, Jul 30, 2024 at 07:46:12PM +0100, Daniel P. Berrangé wrote:
On Tue, Jul 30, 2024 at 02:13:51PM -0400, Peter Xu wrote:
On Mon, Jul 29, 2024 at 06:26
device-specific code, libvirt, and even higher layers like OpenStack).
Regards,
Akihiko Odaki
If a user chooses 2-4), QEMU may enable all offloading features
available on the specified platforms. Again, the user will no longer
have to know each individual performance features. QEMU may also reject
migration to platforms not specified to prevent misconfiguration.
The -platform proposal earlier corresponds to 3). However it has a
downside that QEMU needs to know about platforms, which may not be
trivial. In that case, we can support 1), 2), and 4).
Regards,
Akihiko Odaki
On 2024/07/30 12:45, Jason Wang wrote:
On Tue, Jul 30, 2024 at 11:29 AM Akihiko Odaki wrote:
On 2024/07/30 12:17, Jason Wang wrote:
On Tue, Jul 30, 2024 at 11:12 AM Akihiko Odaki wrote:
On 2024/07/30 12:03, Jason Wang wrote:
On Tue, Jul 30, 2024 at 10:57 AM Akihiko Odaki wrote:
On
On 2024/07/30 12:17, Jason Wang wrote:
On Tue, Jul 30, 2024 at 11:12 AM Akihiko Odaki wrote:
On 2024/07/30 12:03, Jason Wang wrote:
On Tue, Jul 30, 2024 at 10:57 AM Akihiko Odaki wrote:
On 2024/07/30 11:04, Jason Wang wrote:
On Tue, Jul 30, 2024 at 12:43 AM Akihiko Odaki wrote:
On
On 2024/07/30 12:03, Jason Wang wrote:
On Tue, Jul 30, 2024 at 10:57 AM Akihiko Odaki wrote:
On 2024/07/30 11:04, Jason Wang wrote:
On Tue, Jul 30, 2024 at 12:43 AM Akihiko Odaki wrote:
On 2024/07/29 23:29, Peter Xu wrote:
On Mon, Jul 29, 2024 at 01:45:12PM +0900, Akihiko Odaki wrote
On 2024/07/30 11:04, Jason Wang wrote:
On Tue, Jul 30, 2024 at 12:43 AM Akihiko Odaki wrote:
On 2024/07/29 23:29, Peter Xu wrote:
On Mon, Jul 29, 2024 at 01:45:12PM +0900, Akihiko Odaki wrote:
On 2024/07/29 12:50, Jason Wang wrote:
On Sun, Jul 28, 2024 at 11:19 PM Akihiko Odaki wrote
er 2020. If we follow this platform
support, a new feature added to upstream Linux may take about 4 years
before it gets enabled by default on QEMU.
As an upstream developer, I feel it is too long, but I'm sure there are
different opinions from different perspectives.
Regards,
Akihiko Odaki
, libvirt can request QEMU to analyze
the platform dependency when it creates a new domain. QEMU will then
figure out that the host kernel is capable of USO and bake it as a
platform dependency.
Regards,
Akihiko Odaki
On 2024/07/29 23:29, Peter Xu wrote:
On Mon, Jul 29, 2024 at 01:45:12PM +0900, Akihiko Odaki wrote:
On 2024/07/29 12:50, Jason Wang wrote:
On Sun, Jul 28, 2024 at 11:19 PM Akihiko Odaki wrote:
On 2024/07/27 5:47, Peter Xu wrote:
On Fri, Jul 26, 2024 at 04:17:12PM +0100, Daniel P. Berrangé
On 2024/07/29 12:50, Jason Wang wrote:
On Sun, Jul 28, 2024 at 11:19 PM Akihiko Odaki wrote:
On 2024/07/27 5:47, Peter Xu wrote:
On Fri, Jul 26, 2024 at 04:17:12PM +0100, Daniel P. Berrangé wrote:
On Fri, Jul 26, 2024 at 10:43:42AM -0400, Peter Xu wrote:
On Fri, Jul 26, 2024 at 09:48:02AM
things that we maintain can
already stop making sense in general, because it didn't define the whol
guest ABI..
So AFAIU that's really what we used for years, I hope I didn't overlook
somehting. And maybe we don't yet need the "-platform" layer if we can
keep up with this rule?
I think a device which cannot conform to that rule should be
non-migratable. For example, virtio-gpu-gl does not conform to it, and
does not support migration either.
Regards,
Akihiko Odaki
38 matches
Mail list logo
