If a pci address had a function number out of range, the error message
would be:

  Insufficient specification for PCI address

which is logged by virDevicePCIAddressParseXML() after
virDevicePCIAddressIsValid returns a failure.

This patch enhances virDevicePCIAddressIsValid() to optionally report
the error itself (since it is the place that decides which part of the
address is "invalid"), and uses that feature when calling from
virDevicePCIAddressParseXML(), so that the error will be more useful,
e.g.:

  Invalid PCI address function=0x8, must be <= 7

Previously, virDevicePCIAddressIsValid didn't check for the
theoretical limits of domain or bus, only for slot or function. While
adding log messages, we also correct that ommission. (The RNG for PCI
addresses already enforces this limit, which by the way means that we
can't add any negative tests for this - as far as I know our
domainschematest has no provisions for passing XML that is supposed to
fail).

Note that virDevicePCIAddressIsValid() can only check against the
absolute maximum attribute values for *any* possible PCI controller,
not for the actual maximums of the specific controller that this
device is attaching to; fortunately there is later more specific
validation for guest-side PCI addresses when building the set of
assigned PCI addresses. For host-side PCI addresses (e.g. for
<hostdev> and for network device pools), we rely on the error that
will be logged when it is found that the device doesn't actually
exist.

This resolves:

  https://bugzilla.redhat.com/show_bug.cgi?id=1004596

https://bugzilla.redhat.com/show_bug.cgi?id=1176020

Some users think this is a good idea:

      <vcpu placement='static'>4</vcpu>
      <cpu mode='host-model'>
        <model fallback='allow'/>
        <numa>
          <cell id='0' cpus='0-1' memory='1048576' unit='KiB'/>
          <cell id='1' cpus='9-10' memory='2097152' unit='KiB'/>
        </numa>
      </cpu>

It's not. Lets therefore introduce a check and discourage them in
doing so.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The recent changes to perform SCSI device address checks during the
post parse callbacks ran afoul of the Coverity checker since the changes
assumed that the 'xmlopt' parameter to virDomainDeviceDefPostParse
would be non NULL (commit id 'ca2cf74e'); however, what was missed
is there was an "if (xmlopt &&" check being made, so Coverity believed
that it could be possible for a NULL 'xmlopt'.

Checking the various calling paths seemingly disproves that. If called
from virDomainDeviceDefParse, there were two other possible calls that
would end up dereffing, so that path could not be NULL. If called via
virDomainDefPostParseDeviceIterator via virDomainDefPostParse there
are two callers (virDomainDefParseXML and qemuParseCommandLine)
which deref xmlopt either directly or through another call.

So I'm removing the check for non-NULL xmlopt.

Rather than provide a somewhat generic error message when the API
returns false, allow the caller to supply a "report = true" option
in order to cause virReportError's to describe which of the 3 paths
that can cause failure.

Some callers don't care about what caused the failure, they just want
to have a true/false - for those, calling with report = false should
be sufficient.

Rather than calling virDomainDiskDefAssignAddress during the parsing of
the XML, moving the setting of disk addresses into the domain/device post
processing.

Commit id '37588b25' which introduced VIR_DOMAIN_DEF_PARSE_DISK_SOURCE
in order to avoid generating the address which wasn't required will not
be affected by this as all it cared about was processing the source XML.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Remove unused xmlopt param
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than calling virDomainHostdevAssignAddress during the parsing
of the XML, move the setting of a default hostdev address to domain/
device post processing.

Since the parse code no longer generates an address, we can remove
the virDomainDefMaybeAddHostdevSCSIcontroller since the call to
virDomainHostdevAssignAddress will attempt to add the controllers
that were not already defined in the XML.

This patch will also enforce that the address type is type 'drive'
when a SCSI subsystem <hostdev> element is provided with an <address>.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If virDomainControllerSCSINextUnit failed to find a slot on the current
VIR_DOMAIN_CONTROLLER_TYPE_SCSI controller(s), try to add a new controller;
otherwise, there may be multiple unit=0 entries for the same "next"
controller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

While searching the hostdevs the drive type can be either *_TYPE_DRIVE
or *_TYPE_NONE.  If the type is _TYPE_NONE on the first scsi_host, then
there is an erroneous "match" that the address already exists.

Although this works by chance currently because hostdev's are added one
at a time and 'nhostdevs' would be zero, thus returning false for the
first hostdev added, a future patch will move the hostdev address
assignment into post processing resulting in the bad match.

This code is only called by path's expecting either drive or none.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add the xmlopt parameter that was saved during virDomainDefPostParse
to the parameters. A future patch will use it.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move the functions above the post processing for upcoming patch
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Modify virDomainDriveAddressIsUsedBy{Disk|Hostdev} and
virDomainSCSIDriveAddressIsUsed to take 'bus' and 'target'
parameters.  Will be used by future patches for more complete
address conflict checks
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since the only way virDomainHostdevAssignAddress can be called is from
within virDomainHostdevDefParseXML when hostdev->source.subsys.type is
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI, thus there's no need for redundancy.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

There are some non-0 default values in virDomainControllerDef (and
will soon be more) that are easier to not forget if the remembering is
done by a single initializer function (rather than inline code after
allocating the obejct with generic VIR_ALLOC().

If one calls update-device with information that is not updatable,
libvirt reports success even though no data were updated.  The example
used in the bug linked below uses updating device with <boot order='2'/>
which, in my opinion, is a valid thing to request from user's
perspective.  Mainly since we properly error out if user wants to update
such data on a network device for example.

And since there are many things that might happen (update-device on disk
basically knows just how to change removable media), check for what's
changing and moreover, since the function might be usable in other
drivers (updating only disk path is a valid possibility) let's abstract
it for any two disks.

We can't possibly check for everything since for many fields our code
does not properly differentiate between default and unspecified values.
Even though this could be changed, I don't feel like it's worth the
complexity so it's not the aim of this patch.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1007228

In commit 714b38cb I tried to avoid
having two disks with the same WWN in a VM. I forgot to check the
hotplug paths though which make it possible bypass that check. Reinforce
the fix by checking the wwn when attaching the disk.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1208009

There are multiple consumers for the domain condition and we should
always wake them all.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

We should distinguish between success and timeout, to let the user
handle those two events differently.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1142631

Commit id 'e0e29055' added a check to determine if the same bus
had the same target value.  It seems that's not quite good enough
as the check should check the target name value regardless of bus type.

Also added a DO_TEST_DIFFERENT to exhibit the issue

As the backend of shmem server is a unix type chr device, save it in
virDomainChrSourceDef, so we can reuse the existing code for chr device.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Using a custom device tree image may cause unexpected behavior in
architectures that use this approach to detect platform devices. Since
usually the device tree is generated by qemu and thus it's not normally
used let's taint VMs using it to make it obvious as a possible source of
problems.

https://bugzilla.redhat.com/show_bug.cgi?id=1201143

The formatdomain.html description for <disk> device 'lun' indicates that
it must be either a type 'block' or type 'network' with protocol 'iscsi';
however, we did not make that check until domain startup.

This caused issues for virt-manager which had an unexpected failure at
run time rather config time.

This patch adds a check in post part disk device checking for the specific
and supported lun types as well as adjusting the test failure to be for
parse config rather than run time.

https://bugzilla.redhat.com/show_bug.cgi?id=1235116

According to our XML definition, zero is as valid as any other value.
Mainly because it should be kernel-agnostic.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

This patch provides support for the new watchdog model "diag288".
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
Reviewed-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com>

This patch provides support for a new watchdog action "inject-nmi" which
allows to define an inject of a non-maskable interrupt into a guest.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
Reviewed-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com>

Commit id '1feaccf0' attempted to handle an empty secrettype value; however,
it made a mistake by processing the secretType as if it was the original
secrettype string.  The 'secretType' is actually whether 'usage' or 'uuid'
was used.

Thus adjust part of the change to make the same check for def->src->type !=
VIR_STORAGE_TYPE_VOLUME before setting auth_secret_usage from the
secrettype field.

Luckily the aforementioned commits misdeed would be overwritten by the
call to virStorageTranslateDiskSourcePool

Just refactor existing code to use a child buf instead of
check all element before format <blkiotune> and <cputune>.
This will avoid the more and more bigger element check during
we introduce new elements in <blkiotune> and <cputune> in the
future.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

We require the scheduler name attribute in the schemas but the code
would actually be fine when it was omitted. Make it mandatory.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1234729

The SCSI Architecture Model defines a logical unit address
as 64-bits in length, so change the field accordingly so
that the entire value could be stored.
Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>

The address elements are all unsigned integers, so we should
use the appropriate print directive when printing it.
Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>

The SCSI address element attributes bus, target, and unit are expected
to be positive values, so make sure no one provides a negative value since
the value is stored as an unsigned.
Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>

So that they can format private data (e.g., disk private data) stored
elsewhere in the domain object.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Complex jobs, such as migration, need to monitor several events at once,
which is impossible when each of the event uses its own condition
variable. This patch adds a single condition variable to each domain
object. This variable can be used instead of the other event specific
conditions.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The disk is not changed anywhere in the function. Mark this fact
in the function header too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

virDomainObjGetOneDef will help to retrieve the correct definition
pointer from @vm in cases where VIR_DOMAIN_AFFECT_LIVE and
VIR_DOMAIN_AFFECT_CONFIG are mutually exclusive. The function simply
returns the correct pointer. This similarly to virDomainObjGetDefs will
greatly simplify the code.

If @flags contains only VIR_DOMAIN_AFFECT_CONFIG and @vm is active, the
function would return the active config rather than the persistent one
that it should return. This happened due to the fact that
virDomainObjGetDefs was checking the updated flags which may not contain
VIR_DOMAIN_AFFECT_LIVE if it is not requested even if @vm is active.

Additionally the function would not take the flags into account when
setting the pointers which was later used to determine whether the code
needs to update the given configuration.

The mistake was caught by the virt-test suite.

https://bugzilla.redhat.com/show_bug.cgi?id=1220527

This type of information defines attributes of a system
baseboard. With one exception: board type is yet not implemented
in qemu so it's not introduced here either.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1200206

Commit id '1b4eaa61' added the ability to have a mode='direct' for
an iscsi disk volume.  It relied on virStorageTranslateDiskSourcePool
in order to copy any disk source pool authentication information to
the direct disk volume, but it neglected to also copy the 'secrettype'
field which ends up being used in the domain volume formatting code.
Adding a secrettype for this case will allow for proper formatting later
and allow disk snapshotting to work properly

Additionally libvirtd restart processing would fail to find the domain
since the translation processing code is run after domain xml processing,
so handle the the case where the authdef could have an empty secrettype
field when processing the auth and additionally ignore performing the
actual and expected auth secret type checks for a DISK_VOLUME since that
data will be reassembled later during translation processing of the
running domain.

A variable can't be named system, obviously. Well, it can if the
compiler is new enough to distinguish a variable named system and a
function call system(). And some older systems, don't have wise
compiler.

  CC     util/libvirt_util_la-virsysinfo.lo
cc1: warnings being treated as errors
../../src/util/virsysinfo.c: In function 'virSysinfoParseSystem':
../../src/util/virsysinfo.c:649: error: declaration of 'system' shadows a global declaration [-Wshadow]
/usr/include/stdlib.h:717: error: shadowed declaration is here [-Wshadow]
make[3]: *** [util/libvirt_util_la-virsysinfo.lo] Error 1
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>