Signed-off-by: NChen Hanxiao <chen_han_xiao@126.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Support downscript for booting vm,
and hotunplug interface device.
Signed-off-by: NChen Hanxiao <chen_han_xiao@126.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

https://gitlab.com/libvirt/libvirt/-/issues/13

Add support for downscript:

<interface type='ethernet'>
    <mac address='00:11:22:33:44:55'/>
    <script path='/etc/qemu-ifup'/>
    <downscript path='/path/to/my/downscript'/>
</interface>
Signed-off-by: NChen Hanxiao <chen_han_xiao@126.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

With newer pycodestyle 2.6.0 (which is part of flake8-3.8.2) reports
the following pep violation during syntax-check:

../scripts/check-remote-protocol.py:95:9: E741 ambiguous variable name 'l'
    for l in err.strip().split("\n")

On all the distros we test on, this hasn't occurred yet, but with the
future update of flake8 it likely would. The fix is easy, just name the
variable appropriately.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The stepping range (10-11) is likely incomplete. QEMU uses 10 and the
CPUID data for Cooperlake show 11. We will update the range if needed
once more details about he CPU are available.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Commit v3.10.0-182-g237f045d ("qemu: Ignore fallback CPU attribute
on reconnect") forced CPU 'fallback' to ALLOW, regardless of user
choice. This fixed a situation in which guests created with older
Libvirt versions, which used CPU mode 'host-model' in runtime, would
fail to launch in a newer Libvirt if the fallback was set to FORBID.
This would lead to a scenario where the CPU was translated to 'host-model'
to 'custom', but then the FORBID setting would make the translation
process fail.

PSeries can operate with 'host-model' in runtime due to specific PPC64
mechanics regarding compatibility mode. The update() implementation of
the cpuDriverPPC64 driver is a NO-OP if CPU mode is 'host-model', and
the driver does not implement translate(). The commit mentioned above
is causing PSeries guests to get their 'fallback' setting to ALLOW,
overwriting user choice, exposing a design problem in
qemuProcessRefreshCPU() - for PSeries guests, handling 'host-model'
as it is being done does not apply.

All other cpuArchDrivers implements update() and changes guest mode
to VIR_CPU_MODE_CUSTOM, meaning that PSeries is currently the only
exception to this logic. Let's make it official.

https://bugzilla.redhat.com/show_bug.cgi?id=1660711Suggested-by: NJiri Denemark <jdenemar@redhat.com>
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200525123945.4049591-2-danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The host CPU related info stored in the capabilities cache is no longer
valid after the host CPU changes. This is not a frequent situation in
real world, but it can easily happen in nested scenarios when a disk
image is started with various CPUs.

https://bugzilla.redhat.com/show_bug.cgi?id=1778819Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The purpose of this function is to give a short description that would
be change when a host CPU is replaced with a different model. This is
currently implemented by reading /proc/cpuinfo.

It should be implemented for all architectures for which the QEMU driver
stores host CPU data in the capabilities cache. In other words for archs
that support host-model CPUs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use automatic cleanup on qemuProcessUpdateCPU and the functions called
by it.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200522195620.3843442-5-danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Use automatic cleanup of variables.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200522195620.3843442-4-danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Use automatic cleanup of variables.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200522195620.3843442-3-danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Use automatic cleanup of variables.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200522195620.3843442-2-danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NHan Han <hhan@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Currently the value for an enum is only emitted if it is a plain
string. If the enum is an integer or hex value, or a complex code block,
it is omitted from the API build. This fixes that by emitting the raw
value if no string value is present.

With this change:

  <macro name='LIBVIR_CHECK_VERSION'
         file='libvirt-common'
         params='major,minor,micro'>
  <macro name='LIBVIR_VERSION_NUMBER'
         file='libvirt-common'>
  <macro name='VIR_COPY_CPUMAP'
         file='libvirt-domain'
         params='cpumaps,maplen,vcpu,cpumap'>
  ...snip...

  <macro name='LIBVIR_CHECK_VERSION'
         file='libvirt-common'
         params='major,minor,micro'
         raw='((major) * 1000000 + (minor) * 1000 + (micro) <= LIBVIR_VERSION_NUMBER)'>
  <macro name='LIBVIR_VERSION_NUMBER'
         file='libvirt-common'
         raw='6004000'>
  <macro name='VIR_COPY_CPUMAP'
         file='libvirt-domain'
         params='cpumaps,maplen,vcpu,cpumap'
         raw='memcpy(cpumap, VIR_GET_CPUMAP(cpumaps, maplen, vcpu), maplen)'>
  ...snip...
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Currently the information about enums in the API document lacks any
mention of parameters, so it is impossible to tell what kind of enum
declaration is present in the libvirt API header. With this change

  <macro name='LIBVIR_CHECK_VERSION' file='libvirt-common'>
  <macro name='VIR_COPY_CPUMAP' file='libvirt-domain'>
  ...snip...

becomes

  <macro name='LIBVIR_CHECK_VERSION' file='libvirt-common' params='major,minor,micro'>
  <macro name='VIR_COPY_CPUMAP' file='libvirt-domain' params='cpumaps,maplen,vcpu,cpumap'>
  ...snip...
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The API build script tokenizes enums declarations by first splitting on
whitespace. This is unhelpful as it means an enum

 # define VIR_USE_CPU(cpumap, cpu) ((cpumap)[(cpu) / 8] |= (1 << ((cpu) % 8)))

Gets tokenized as

  #define
  VIR_USE_CPU(cpumap,
  cpu)
  ((cpumap)[(cpu)
  /
  8]
  |=
  (1
  <<
  ((cpu)
  %
  8)))

With this change, the set of parameters are all merged into the first
token:

  #define
  VIR_USE_CPU(cpumap,cpu)
  ((cpumap)[(cpu)
  /
  8]
  |=
  (1
  <<
  ((cpu)
  %
  8)))

which is more convenient to process later on in the script.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The build system will be running in UTF-8 locale, so any content in the
API XML files will also end up being UTF-8, not ISO-8859-1.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Some of the node device xml schema was documented in drvnodedev.html.in
rather than in formatnode.html.in. Move all of the schema documentation
to formatnode.html.in and provide reference links from the
drvnodedev.html.in page.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

The proper name for physical function capability is 'phys_function', not
'physical_function'. Likewise, a virtual function capability is
'virt_functions' rather than 'virtual_function'.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NErik Skultety <eskultet@redhat.com>

Currently, the @vm is passed in as an argument and
testCompareXMLToArgvCreateArgs() is called over it which means
under the hood qemuProcessPrepareDomain() is called. But at the
point where ValidateSchema() is called, the domain object is
already 'prepared', i.e. all device aliases are assigned and so
on. But our code is not prepared to 'prepare' a domain twice - it
simply overwrites all the pointers leading to a memory leak.

Fortunately, this is only the problem of this test.

Resolve this by constructing the domain object from scratch.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

The intention of these split Load*Entry functions is to prevent
virQEMUDriverConfigLoadFile from getting too large.

There's no need to signal to the caller whether an entry was found
or not, only whether there was an error.

Remove the non-standard return 1.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

virConfGetValueString returns an allocated string that needs to be
freed.

Fixes: 34a59fb5Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

There are 4 formats available (x:stderr, x:syslog:name,
x:file:file_path, x:journald), not 3. Use "the following"
instead of the actual number to avoid the need to update
the number every time a new form is added/removed.
Suggested-by: NPino Toscano <ptoscano@redhat.com>
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Our hotplug test cases are weak in comparison to the qemuxml2argvtest.
Use all the the input data to also validate the arguments for -netdev
and -blockdev against the appropriate commands of the QMP schema.

Note that currently it's done just for the _CAPS versions of tests but
commenting out a line in the test file allows to validate even cases
which don't use real capabilities.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Add testQEMUSchemaLoad and refactor internals so that we can load the
QMP schema from an arbitrary caps replies file.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

It always loads the latest schema. Prepare for loading others as well.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

qemuxml2argv test suite is way more comprehensive than the hotplug
suite. Since we share the code paths for monitor and command line
hotplug we can easily test the properties of devices against the QAPI
schema.

To achieve this we'll need to skip the JSON->commandline conversion for
the test run so that we can analyze the pure properties. This patch adds
flags for the comand line generator and hook them into the
JSON->commandline convertor for -netdev. An upcoming patch will make use
of this new infrastructure.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Now that all code paths generate JSON props we can remove the conversion
to command line arguments and back in the monitor code.

Note that the test which is removed in this commit will be replaced by a
stronger testsuite later.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Syntax of guestfwd channel also needs to be modified to conform to the
QAPI schema.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

QEMU models guestfwd as:

 'guestfwd': [
                 { "str": "tcp:10.0.2.1:4600-chardev:charchannel0" },
                 { "str": "...."},
             ]

but the command line as:

guestfwd=tcp:10.0.2.1:4600-chardev:charchannel0,guestfwd=...

I guess the original idea was to make it extensible while not worrying
about adding another object for it. Either way it requires us to add yet
another JSON->cmdline convertor for arrays.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

The 'netdev_add' command was recently formally described in qemu via the
QMP schema. This means that it also requires the arguments to be
properly formatted. Our current approach is to generate the command line
and then use qemuMonitorJSONKeywordStringToJSON to get the JSON
properties for the monitor. This will not work if we need to pass some
fields as numbers or booleans.

In this step we re-do internals of qemuBuildHostNetStr to format a JSON
object which is converted back via virQEMUBuildNetdevCommandlineFromJSON
to the equivalent command line. This will later allow fixing of the
monitor code to use the JSON object directly rather than rely on the
conversion.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

In preparation for converting the generator of -netdev to generate JSON
which will be used to do the command line rather than the other way
around we need to introduce a convertor which properly configures
virQEMUBuildCommandLineJSON for the quirks of -netdev.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>