Re: [libvirt] [PATCH v2 1/3] qemu: add vfio-ap capability
Quoting Thomas Huth (2018-10-19 06:58:34)
> On 2018-10-18 16:54, Boris Fiuczynski wrote:
> > Introduce vfio-ap capability.
> >
> > Signed-off-by: Boris Fiuczynski
> > Reviewed-by: Bjoern Walk
> > ---
> > src/qemu/qemu_capabilities.c | 2 ++
> > src/qemu/qemu_capabilities.h | 1 +
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> > index e228f52ec0..2ca5af3297 100644
> > --- a/src/qemu/qemu_capabilities.c
> > +++ b/src/qemu/qemu_capabilities.c
> > @@ -508,6 +508,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
> >/* 315 */
> >"vfio-pci.display",
> >"blockdev",
> > + "vfio-ap",
> > );
> >
The statement "On s390, we have cryptographic coprocessor cards,
which are modeled on Linux as devices on the AP bus."
was made in email titled "s390: vfio-ap: guest dedicated crypto adapters"
Does this imply other devices can exist on an AP Bus?
Any chance this should be something like "vfio-ap.crypto" in the same
way a "vfio-pci.display" entry is listed above seemingly implying a
display device on a more generic pci bus? Or does "vfio-ap" always imply
crypto?
Having difficulty sorting out the relationships between adjunct
processor, crypto processor and ap bus from the patch docs and initial
review of the references.
> >
> > @@ -1092,6 +1093,7 @@ struct virQEMUCapsStringFlags
> > virQEMUCapsObjectTypes[] = {
> > { "vhost-vsock-device", QEMU_CAPS_DEVICE_VHOST_VSOCK },
> > { "mch", QEMU_CAPS_DEVICE_MCH },
> > { "sev-guest", QEMU_CAPS_SEV_GUEST },
> > +{ "vfio-ap", QEMU_CAPS_DEVICE_VFIO_AP },
> > };
> >
> > static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVirtioBalloon[]
> > = {
> > diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
> > index 934620ed31..6bb9a2c8f0 100644
> > --- a/src/qemu/qemu_capabilities.h
> > +++ b/src/qemu/qemu_capabilities.h
> > @@ -492,6 +492,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for
> > syntax-check */
> > /* 315 */
> > QEMU_CAPS_VFIO_PCI_DISPLAY, /* -device vfio-pci.display */
> > QEMU_CAPS_BLOCKDEV, /* -blockdev and blockdev-add are supported */
> > +QEMU_CAPS_DEVICE_VFIO_AP, /* -device vfio-ap */
> >
> > QEMU_CAPS_LAST /* this must always be the last item */
> > } virQEMUCapsFlags;
> >
>
> Reviewed-by: Thomas Huth
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 3/3] news: Update news for vfio-ap support
Quoting Thomas Huth (2018-10-19 07:19:35) > On 2018-10-18 16:54, Boris Fiuczynski wrote: > > Signed-off-by: Boris Fiuczynski > > --- > > docs/news.xml | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/docs/news.xml b/docs/news.xml > > index dc08c96352..e5476a3332 100644 > > --- a/docs/news.xml > > +++ b/docs/news.xml > > @@ -35,6 +35,15 @@ > > > > > > > > + > > + > > + qemu: Add vfio AP support > > + > > + > > + The QEMU driver now has support to passthrough adjunct processors > > + into QEMU guests on S390. > > + > > + > > > > > > > > Reviewed-by: Thomas Huth Reviewed-by: Chris Venteicher > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/11] Avoid numerous calls of virQEMUCapsCacheLookup
On Thu, Sep 20, 2018 at 07:44:46PM +0200, Marc Hartmayer wrote:
> For a domain definition there are numerous calls of
> virQEMUCapsCacheLookup (the same applies to the domain start). This
> slows down the process since virQEMUCapsCacheLookup validates that the
> QEMU capabilitites are still valid (among other things, a fork is done
> for this if the user for the QEMU processes is 'qemu'). Therefore
> let's reduce the number of virQEMUCapsCacheLookup calls whenever
> possible and reasonable.
>
> In addition to the speed up, there is the risk that
> virQEMUCapsCacheLookup returns different QEMU capabilities during a
> task if, for example, the QEMU binary has changed during the task.
>
> The correct way would be:
>
> - get the QEMU capabilities only once per task via virQEMUCapsCacheLookup
> - do the task with these QEMU capabilities
>
> or
>
> - abort the task after a cache invalidation
>
> Note: With this patch series the behavior is still not (completely)
> fixed, but the performance has been significantly improved. In a quick
> test this gave a speed up of factor 4 for a simple define/undefine
> loop.
>
> In general, the more devices a domain has, the more drastic the
> overhead becomes (because a cache validation is performed for each
> device).
IIUC from your KVM Forum presentation, the overhead of the
cache lookup is almost entirely coming from the fork() call
triggered by the single call
kvmUsable = virFileAccessibleAs("/dev/kvm", R_OK | W_OK,
priv->runUid, priv->runGid) == 0;
Rather than the major refactor of the way the parse callbacks
work, we could instead just optimize this call to avoid the
repeated forks.
Even if we reduced the number of calls to the cache, it is
still somewhat overkill to be checking /dev/kvm via fork()
every time. eg even if you reduced it to just a single
cache lookup, if you run virDomainDefine for 100 domains
in parallel it is still going to do 100 forks.
We could optimize this by jcalling virFileAccessibleAs
once and storing the result in a global. Then just do a
plain stat() call in process to check the st_ctime field
for changes. We only need re-run the heavy virFileAccessibleAs
check if st_ctime has changed (indicating a owner/group/acl
change).
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PULL 00/45] Machine queue, 2018-10-18
On 19/10/2018 22:23, Eduardo Habkost wrote:
On Fri, Oct 19, 2018 at 09:53:45PM +0200, Igor Mammedov wrote:
On Fri, 19 Oct 2018 15:44:08 -0300
Eduardo Habkost wrote:
On Fri, Oct 19, 2018 at 03:12:31PM +0100, Peter Maydell wrote:
On 18 October 2018 at 21:03, Eduardo Habkost wrote:
The following changes since commit 09558375a634e17cea6cfbfec883ac2376d2dc7f:
Merge remote-tracking branch
'remotes/pmaydell/tags/pull-target-arm-20181016-1' into staging (2018-10-16
17:42:56 +0100)
are available in the Git repository at:
git://github.com/ehabkost/qemu.git tags/machine-next-pull-request
for you to fetch changes up to 6d8e1bcc7dd5e819ce81e6a87fffe23e39c700cc:
numa: Clean up error reporting in parse_numa() (2018-10-17 16:33:40 -0300)
Machine queue, 2018-10-18
* sysbus init/realize cleanups
(Cédric Le Goater, Philippe Mathieu-Daudé)
* memory-device refactoring (David Hildenbrand)
* -smp: deprecate incorrect CPUs topology (Igor Mammedov)
* -numa parsing cleanups (Markus Armbruster)
* Fix hostmem-file memory leak (Zhang Yi)
* Typo fix (Li Qiang)
Hi. This had some problems in merge testing, I'm afraid:
On aarch64 host, warnings running tests/cpu-plug-test for i386 and s390 targets:
TEST: tests/cpu-plug-test... (pid=12602)
/i386/cpu-plug/pc-i440fx-3.0/cpu-add/1x3x2=12:
qemu-system-i386: warning: Invalid CPU topology deprecated: sockets
(1) * cores (3) * threads (2) != maxcpus (12)
[...]
(plus similar ppc64, x86_64 targets)
Ouch. Apologies.
Can we please do something make sure "make check" will fail on
these cases? I'd like to be able to trust CI systems like
travis-ci.
we probably don't want make check fail on warning.
I disagree. If a warning is blocking a pull request from being
merged, it must make CI systems fail too. Otherwise we're
defeating the purpose of CI systems.
We can, we also have the hardware (courtesy of Packet), we just need to
make time to set it up.
QEMU Summit is a good place where to talk about this.
Test was written with assumption that s/c/t tuples matches initially present
CPUs, hence a warning.
Would something like following fix the issue (local x86 build/test looks fixed
with it)?
It works for me. I will queue it on machine-next, thanks!
diff --git a/tests/cpu-plug-test.c b/tests/cpu-plug-test.c
index 3e93c8e..f4a677d 100644
--- a/tests/cpu-plug-test.c
+++ b/tests/cpu-plug-test.c
@@ -32,12 +32,12 @@ static void test_plug_with_cpu_add(gconstpointer data)
unsigned int i;
args = g_strdup_printf("-machine %s -cpu %s "
- "-smp sockets=%u,cores=%u,threads=%u,maxcpus=%u",
+ "-smp 1,sockets=%u,cores=%u,threads=%u,maxcpus=%u",
s->machine, s->cpu_model,
s->sockets, s->cores, s->threads, s->maxcpus);
qtest_start(args);
-for (i = s->sockets * s->cores * s->threads; i < s->maxcpus; i++) {
+for (i = 1; i < s->maxcpus; i++) {
response = qmp("{ 'execute': 'cpu-add',"
" 'arguments': { 'id': %d } }", i);
g_assert(response);
@@ -56,7 +56,7 @@ static void test_plug_without_cpu_add(gconstpointer data)
QDict *response;
args = g_strdup_printf("-machine %s -cpu %s "
- "-smp sockets=%u,cores=%u,threads=%u,maxcpus=%u",
+ "-smp 1,sockets=%u,cores=%u,threads=%u,maxcpus=%u",
s->machine, s->cpu_model,
s->sockets, s->cores, s->threads, s->maxcpus);
qtest_start(args);
@@ -79,12 +79,12 @@ static void test_plug_with_device_add_x86(gconstpointer
data)
unsigned int s, c, t;
args = g_strdup_printf("-machine %s -cpu %s "
- "-smp sockets=%u,cores=%u,threads=%u,maxcpus=%u",
+ "-smp 1,sockets=%u,cores=%u,threads=%u,maxcpus=%u",
td->machine, td->cpu_model,
td->sockets, td->cores, td->threads, td->maxcpus);
qtest_start(args);
-for (s = td->sockets; s < td->maxcpus / td->cores / td->threads; s++) {
+for (s = 1; s < td->sockets; s++) {
for (c = 0; c < td->cores; c++) {
for (t = 0; t < td->threads; t++) {
char *id = g_strdup_printf("id-%i-%i-%i", s, c, t);
@@ -113,7 +113,7 @@ static void test_plug_with_device_add_coreid(gconstpointer
data)
td->sockets, td->cores, td->threads, td->maxcpus);
qtest_start(args);
-for (c = td->cores; c < td->maxcpus / td->sockets / td->threads; c++) {
+for (c = 1; c < td->cores; c++) {
char *id = g_strdup_printf("id-%i", c);
qtest_qmp_device_add(td->device_model, id, "{'core-id':%u}", c);
g_free(id);
@@ -148,7 +148,7 @@ static void add_pc_test_case(const char *mname)
Re: [libvirt] [Qemu-devel] [PULL 00/45] Machine queue, 2018-10-18
On Fri, Oct 19, 2018 at 7:00 PM Philippe Mathieu-Daudé
wrote:
> On 19/10/2018 16:12, Peter Maydell wrote:
...
> >>
> >>
> >
> > Hi. This had some problems in merge testing, I'm afraid:
> >
> > On aarch64 host, warnings running tests/cpu-plug-test for i386 and s390
> > targets:
> >
> > TEST: tests/cpu-plug-test... (pid=12602)
> > /i386/cpu-plug/pc-i440fx-3.0/cpu-add/1x3x2=12:
> > qemu-system-i386: warning: Invalid CPU topology deprecated: sockets
> > (1) * cores (3) * threads (2) != maxcpus (12)
> > OK
> > /i386/cpu-plug/pc-i440fx-3.0/device-add/1x3x2=12:
> > qemu-system-i386: warning: Invalid CPU topology deprecated: sockets
> > (1) * cores (3) * threads (2) != maxcpus (12)
> > OK
> > /i386/cpu-plug/pc-q35-3.0/cpu-add/1x3x2=12:
> > qemu-system-i386: warning: Invalid CPU topology deprecated: sockets
> > (1) * cores (3) * threads (2) != maxcpus (12)
> > OK
> > /i386/cpu-plug/pc-q35-3.0/device-add/1x3x2=12:
> > qemu-system-i386: warning: Invalid CPU topology deprecated: sockets
> > (1) * cores (3) * threads (2) != maxcpus (12)
> > OK
> > /arm/qom/n800: OK
> > PASS: tests/cpu-plug-test
> > [...]
> > TEST: tests/cpu-plug-test... (pid=15040)
> > /s390x/cpu-plug/s390-ccw-virtio-3.1/cpu-add/1x3x1=6:
> > qemu-system-s390x: warning: Invalid CPU topology deprecated: sockets
> > (1) * cores (3) * threads (1) != maxcpus (6)
> > OK
> > /s390x/cpu-plug/s390-ccw-virtio-3.1/device-add/1x3x1=6:
> > qemu-system-s390x: warning: Invalid CPU topology deprecated: sockets
> > (1) * cores (3) * threads (1) != maxcpus (6)
> > OK
> > /s390x/cpu-plug/s390-ccw-virtio-3.0/cpu-add/1x3x1=6:
> > qemu-system-s390x: warning: Invalid CPU topology deprecated: sockets
> > (1) * cores (3) * threads (1) != maxcpus (6)
> > OK
> > /s390x/cpu-plug/s390-ccw-virtio-3.0/device-add/1x3x1=6:
> > qemu-system-s390x: warning: Invalid CPU topology deprecated: sockets
> > (1) * cores (3) * threads (1) != maxcpus (6)
> > OK
> > PASS: tests/cpu-plug-test
> >
> > (plus similar ppc64, x86_64 targets)
> >
> > I see similar warnings on hosts SPARC, PPC64BE, S390, 32-bit Arm
> > and x86 FreeBSD.
> >
> > I also got a build failure on one of my configs, but I think that
> > is caused by some latent bug in our makefiles where we don't
> > correctly rebuild x86_64-softmmu/config-devices.mak when a
> > change is made to default-configs/i386-softmmu.mak -- doing a
> > hand rm of the config-devices.mak fixed it.
>
> bisected to:
>
> 23d0571a24559b867fa47410aa8ec0519b0a1edd is the first bad commit
> commit 23d0571a24559b867fa47410aa8ec0519b0a1edd
> Author: Igor Mammedov
> Date: Thu Sep 13 13:06:01 2018 +0200
>
> vl.c deprecate incorrect CPUs topology
>
> -smp [cpus],sockets/cores/threads[,maxcpus] should describe topology
> so that total number of logical CPUs [sockets * cores * threads]
> would be equal to [maxcpus], however historically we didn't have
> such check in QEMU and it is possible to start VM with an invalid
> topology.
> Deprecate invalid options combination so we can make sure that
> the topology VM started with is always correct in the future.
> Users with an invalid sockets/cores/threads/maxcpus values should
> fix their CLI to make sure that
>[sockets * cores * threads] == [maxcpus]
Per the commit message, I understand the tests need to be upgraded,
they only test it is <= maxcpus while now we want == maxcpus:
static void add_s390x_test_case(const char *mname)
{
...
data->sockets = 1;
data->cores = 3;
data->threads = 1;
data->maxcpus = data->sockets * data->cores * data->threads * 2;
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PULL 00/45] Machine queue, 2018-10-18
On 19/10/2018 16:12, Peter Maydell wrote: > On 18 October 2018 at 21:03, Eduardo Habkost wrote: >> The following changes since commit 09558375a634e17cea6cfbfec883ac2376d2dc7f: >> >> Merge remote-tracking branch >> 'remotes/pmaydell/tags/pull-target-arm-20181016-1' into staging (2018-10-16 >> 17:42:56 +0100) >> >> are available in the Git repository at: >> >> git://github.com/ehabkost/qemu.git tags/machine-next-pull-request >> >> for you to fetch changes up to 6d8e1bcc7dd5e819ce81e6a87fffe23e39c700cc: >> >> numa: Clean up error reporting in parse_numa() (2018-10-17 16:33:40 -0300) >> >> >> Machine queue, 2018-10-18 >> >> * sysbus init/realize cleanups >> (Cédric Le Goater, Philippe Mathieu-Daudé) >> * memory-device refactoring (David Hildenbrand) >> * -smp: deprecate incorrect CPUs topology (Igor Mammedov) >> * -numa parsing cleanups (Markus Armbruster) >> * Fix hostmem-file memory leak (Zhang Yi) >> * Typo fix (Li Qiang) >> >> >> > > Hi. This had some problems in merge testing, I'm afraid: > > On aarch64 host, warnings running tests/cpu-plug-test for i386 and s390 > targets: > > TEST: tests/cpu-plug-test... (pid=12602) > /i386/cpu-plug/pc-i440fx-3.0/cpu-add/1x3x2=12: > qemu-system-i386: warning: Invalid CPU topology deprecated: sockets > (1) * cores (3) * threads (2) != maxcpus (12) > OK > /i386/cpu-plug/pc-i440fx-3.0/device-add/1x3x2=12: > qemu-system-i386: warning: Invalid CPU topology deprecated: sockets > (1) * cores (3) * threads (2) != maxcpus (12) > OK > /i386/cpu-plug/pc-q35-3.0/cpu-add/1x3x2=12: > qemu-system-i386: warning: Invalid CPU topology deprecated: sockets > (1) * cores (3) * threads (2) != maxcpus (12) > OK > /i386/cpu-plug/pc-q35-3.0/device-add/1x3x2=12: > qemu-system-i386: warning: Invalid CPU topology deprecated: sockets > (1) * cores (3) * threads (2) != maxcpus (12) > OK > /arm/qom/n800: OK > PASS: tests/cpu-plug-test > [...] > TEST: tests/cpu-plug-test... (pid=15040) > /s390x/cpu-plug/s390-ccw-virtio-3.1/cpu-add/1x3x1=6: > qemu-system-s390x: warning: Invalid CPU topology deprecated: sockets > (1) * cores (3) * threads (1) != maxcpus (6) > OK > /s390x/cpu-plug/s390-ccw-virtio-3.1/device-add/1x3x1=6: > qemu-system-s390x: warning: Invalid CPU topology deprecated: sockets > (1) * cores (3) * threads (1) != maxcpus (6) > OK > /s390x/cpu-plug/s390-ccw-virtio-3.0/cpu-add/1x3x1=6: > qemu-system-s390x: warning: Invalid CPU topology deprecated: sockets > (1) * cores (3) * threads (1) != maxcpus (6) > OK > /s390x/cpu-plug/s390-ccw-virtio-3.0/device-add/1x3x1=6: > qemu-system-s390x: warning: Invalid CPU topology deprecated: sockets > (1) * cores (3) * threads (1) != maxcpus (6) > OK > PASS: tests/cpu-plug-test > > (plus similar ppc64, x86_64 targets) > > I see similar warnings on hosts SPARC, PPC64BE, S390, 32-bit Arm > and x86 FreeBSD. > > I also got a build failure on one of my configs, but I think that > is caused by some latent bug in our makefiles where we don't > correctly rebuild x86_64-softmmu/config-devices.mak when a > change is made to default-configs/i386-softmmu.mak -- doing a > hand rm of the config-devices.mak fixed it. bisected to: 23d0571a24559b867fa47410aa8ec0519b0a1edd is the first bad commit commit 23d0571a24559b867fa47410aa8ec0519b0a1edd Author: Igor Mammedov Date: Thu Sep 13 13:06:01 2018 +0200 vl.c deprecate incorrect CPUs topology -smp [cpus],sockets/cores/threads[,maxcpus] should describe topology so that total number of logical CPUs [sockets * cores * threads] would be equal to [maxcpus], however historically we didn't have such check in QEMU and it is possible to start VM with an invalid topology. Deprecate invalid options combination so we can make sure that the topology VM started with is always correct in the future. Users with an invalid sockets/cores/threads/maxcpus values should fix their CLI to make sure that [sockets * cores * threads] == [maxcpus] > > > thanks > -- PMM > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [snmp PATCH] configure: Fix MIB_DIR's prefix
So far we are taking whatever is `net-snmp-config
--default-mibdirs` returns and using that as MIB_DIR to install
our MIB. This has a drawback that it ignores whatever prefix user
specifies to configure script (which is used by `make distcheck`
too). The fix consists of querying for net-snmp-config --prefix
and replacing that in MIB_DIR var.
Signed-off-by: Michal Privoznik
---
This is similar to what we do for wireshark in libvirt.
configure.ac | 8
1 file changed, 8 insertions(+)
diff --git a/configure.ac b/configure.ac
index baac0e1..f729ac1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -73,6 +73,14 @@ if test "x$with_mibdir" = "x" ; then
MIB_DIR=$(echo $MIB_DIR | awk -F : '{print $NF}')
AC_MSG_RESULT([found $MIB_DIR])
+
+dnl Replace net-snmp's exec_prefix with our own.
+dnl Note that ${exec_prefix} is kept verbatim at this point in time,
+dnl and will only be expanded later, when make is called: this makes
+dnl it possible to override such prefix at compilation or installation
+dnl time
+MIB_PREFIX="`$SNMP_CONFIG --prefix`"
+MIB_DIR='${exec_prefix}'"${MIB_DIR#$MIB_PREFIX}"
else
AC_MSG_CHECKING([accessibility of $with_mibdir])
if test ! -d "$with_mibdir" ; then
--
2.18.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
