2:34 a.m.
I'm trying to (optionally) use iothreads, which only exist on qemu-kvm-ev.
I was hoping to see it in the domcapabilities, but I don't see it there.
How do I know if it's supported or not?
TIA,
Y.
3:22 a.m.
On Thu, Oct 19, 2017 at 10:34:21AM +0300, Yaniv Kaul wrote:
I'm trying to (optionally) use iothreads, which only exist on
qemu-kvm-ev.
I was hoping to see it in the domcapabilities, but I don't see it there.
How do I know if it's supported or not?
Well, you can get the emulator binary from /domainCapabilities/path, but that's
not what you should be using for any support-related decisions.
I guess there is no easy way to do that, feel free to create a BZ that we add it
to domcapabilities (or just capabilities maybe) and assign it to me so that we
don't lose track of it. I'll post a patch for it then, it will be trivial, the
only thing we need is design decision about how to name it and where to put it.
HTH,
Martin
TIA,
Y.
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
4:43 a.m.
On Thu, Oct 19, 2017 at 10:22:59AM +0200, Martin Kletzander wrote:
On Thu, Oct 19, 2017 at 10:34:21AM +0300, Yaniv Kaul wrote:
> I'm trying to (optionally) use iothreads, which only exist on qemu-kvm-ev.
> I was hoping to see it in the domcapabilities, but I don't see it there.
> How do I know if it's supported or not?
>
Well, you can get the emulator binary from /domainCapabilities/path, but that's
not what you should be using for any support-related decisions.
I guess there is no easy way to do that, feel free to create a BZ that we add it
to domcapabilities (or just capabilities maybe) and assign it to me so that we
don't lose track of it. I'll post a patch for it then, it will be trivial, the
only thing we need is design decision about how to name it and where to put it.
I don't think that this is something we would like to have in upstream
code. The differentiation between qemu-kvm and qemu-kvm-ev is
dowsntream thing. In addition, there is no qemu-kvm in upstream, there
is only QEMU.
What we can add into capabilities is information whether the QEMU binary
supports iothreads or not, but please, don't introduce anything that's
downstream only.
Pavel
7:43 a.m.
On Thu, Oct 19, 2017 at 11:43:44AM +0200, Pavel Hrdina wrote:
On Thu, Oct 19, 2017 at 10:22:59AM +0200, Martin Kletzander wrote:
> On Thu, Oct 19, 2017 at 10:34:21AM +0300, Yaniv Kaul wrote:
> > I'm trying to (optionally) use iothreads, which only exist on qemu-kvm-ev.
> > I was hoping to see it in the domcapabilities, but I don't see it there.
> > How do I know if it's supported or not?
> >
>
> Well, you can get the emulator binary from /domainCapabilities/path, but that's
> not what you should be using for any support-related decisions.
>
> I guess there is no easy way to do that, feel free to create a BZ that we add it
> to domcapabilities (or just capabilities maybe) and assign it to me so that we
> don't lose track of it. I'll post a patch for it then, it will be trivial,
the
> only thing we need is design decision about how to name it and where to put it.
I don't think that this is something we would like to have in upstream
code. The differentiation between qemu-kvm and qemu-kvm-ev is
dowsntream thing. In addition, there is no qemu-kvm in upstream, there
is only QEMU.
What we can add into capabilities is information whether the QEMU binary
supports iothreads or not, but please, don't introduce anything that's
downstream only.
That's what I meant by "feel free to create a BZ that we add it to
domcapabilities (or just capabilities maybe)", it was meant for the iothread
support. I already have the patch for it, just need to add it to tests.
2591
days inactive
2591
days old
3 comments
3 participants
participants (3)
-
Martin Kletzander -
Pavel Hrdina -
Yaniv Kaul