Once more stuff will be moved into the vCPU data structure it will be
necessary to get a specific one in some ocasions. Add a helper that will
simplify this task.

To allow collecting all relevant data at one place let's make def->vcpus
a structure and then we can start moving stuff into it.

Later on this will also be used to track size of the vcpu data array.
Use size_t so that we can utilize the memory allocation helpers.

Finalize the refactor by adding the 'virDomainDefGetVCpusMax' getter and
reusing it accross libvirt.

The new helper will simplify checking whether the domain config contains
inactive vCPUs.

To support further refactors replace all write access to def->maxvcpus
with a accessor function.

Our domain_conf.* files are big enough. Not only they contain XML
parsing code, but they served as a storage of all functions whose
name is virDomain prefixed. This is just wrong as it gathers not
related functions (and modules) into one big file which is then
harder to maintain. Split virDomainObjList module into a separate
file called virdomainobjlist.[ch].
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add xml for the new virtio-input-host-pci device:
<input type='passthrough' bus='virtio'>
  <source evdev='/dev/input/event1234'/>
</input>

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

To be used by the family of virtio input devices:

<input type='mouse' bus='virtio'/>
<input type='tablet' bus='virtio'/>
<input type='keyboard' bus='virtio'/>

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

qemu 2.5 provides virtio video device.  It can be used with -device
virtio-vga for primary devices, or -device virtio-gpu for non-vga
devices. However, only the primary device (VGA) is supported with this
patch.

Reference:
https://bugzilla.redhat.com/show_bug.cgi?id=1195176Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Allowing to have the extra undefined/default state.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Following the domain XML naming
Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com>

'model' attribute was added to a panic device but only one panic
device is allowed. This patch changes panic device presence
from 'optional' to 'zeroOrMore'.

Libvirt already has two types of panic devices - pvpanic and pSeries firmware.
This patch introduces the 'model' attribute and a new type of panic device.

'isa' model is for ISA pvpanic device.
'pseries' model is a default value for pSeries guests.
'hyperv' model is the new type. It's used for Hyper-V crash.

Schema and docs are updated for the new attribute.

Adjust the config code so that it does not enforce that target memory
node is specified. To avoid breakage, adjust the qemu memory hotplug
config checker to disallow such config for now.

Keep const correctness and allow to use this function in cases where
@def is const in the caller.

Rename the function to virDomainDefCheckDuplicateDiskInfo and make it
check disk serials too.

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

Earlier virtType was of type int. After, introducing the enum VIR_DOMAIN_VIRT_NONE,
the type of virtType is modified to virDomainVirtType.

Introduce VIR_DOMAIN_VIRT_NONE to give domaintype the default value of zero.
This is specially helpful in constructing better error messages
when we don't want to look up the default emulator by virtType.

The test data in vircapstest.c is also modified to reflect this change.

When implementing memory hotplug I've opted to recalculate the initial
memory size (contents of the <memory> element) as a sum of the sizes of
NUMA nodes when NUMA was enabled. This was based on an assumption that
qemu did not allow starting when the NUMA node size total didn't equal
to the initial memory size. Unfortunately the check was introduced to
qemu just lately.

This patch uses the new XML parser flag to decide whether it's safe to
update the memory size total from the NUMA cell sizes or not.

As an additional improvement we now report an error in case when the
size of hotplug memory would exceed the total memory size.

The rest of the changes assures that the function is called with correct
flags.

Add 'initial_memory' member to struct virDomainMemtune so that the
memory size can be pre-calculated once instead of inferring it always
again and again.

Separating of the fields will also allow finer granularity of decisions
in later patches where it will allow to keep the old initial memory
value in cases where we are handling incomming migration from older
versions that did not always update the size from NUMA as the code did
previously.

The change also requires modification of the qemu memory alignment
function since at the point where we are modifying the size of NUMA
nodes the total size needs to be recalculated too.

The refactoring done in this patch also fixes a crash in the hyperv
driver that did not properly initialize def->numa and thus
virDomainNumaGetMemorySize(def->numa) crashed.

In summary this patch should have no functional impact at this point.

The name of the variable was misleading. Rename it and it's setting
accessor before other fixes.

Add a new parser flag that will mark code paths that parse XML files
wich will not be used with existing VM state so that post parse
callbacks can possibly do ABI incompatible changes if needed.

The flag was used only for formatting the XML and once the parser and
formatter flags were split in 0ecd6851
it doesn't make sense any more to have it.

Add a simple helper so that the code doesn't have to rewrite the same
condition multiple times.

I always felt like this function is qemu specific rather than
libvirt-wide. Other drivers may act differently on virDomainDef
change and in fact may require talking to underlying hypervisor
even if something else's than disk->src has changed.  I know that
the function is still incomplete, but lets break that into two
commits that are easier to review. This one is pure code
movement.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Adds a new interface type using UDP sockets, this seems only applicable
to QEMU but have edited tree-wide to support the new interface type.

The interface type required the addition of a "localaddr" (local
address), this then maps into the following xml and qemu call.

<interface type='udp'>
  <mac address='52:54:00:5c:67:56'/>
  <source address='127.0.0.1' port='11112'>
    <local address='127.0.0.1' port='22222'/>
  </source>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</interface>

QEMU call:
	-net socket,udp=127.0.0.1:11112,localaddr=127.0.0.1:22222

Notice the xml "local" entry becomes the "localaddr" for the qemu call.

reference:
http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.htmlSigned-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

We just need to update the entry in the second hash table. Since commit 8728a565
we have two hash tables for the domain list so that we can do O(1) lookup
regardless of looking up by UUID or name. Since with renaming a domain UUID does
not change, we only need to update the second hash table, where domains are
referenced by their name.

We will call both functions from the qemuDomainRename().
Signed-off-by: NTomas Meszaros <exo@tty.sk>

This needs a reorder of XML option definitions.  It might come in handy
one day.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1210587  (completed)

When generating the default drive address for a SCSI <disk> device,
check the generated address to ensure it doesn't conflict with a SCSI
<hostdev> address. The <disk> address generation algorithm uses the
<target> "dev" name in order to determine which controller and unit
in order to place the device. Since a SCSI <hostdev> device doesn't
require a target device name, its placement on the guest SCSI address
"could" conflict.  For instance, if a SCSI <hostdev> exists at
controller=0 unit=0 and an attempt to hotplug 'sda' into the guest
made, there would be a conflict if the <hostdev> is already using
/dev/sda.

This will be used with a virtio-scsi controller later on.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This controller can be connected only to a port on a
pcie-switch-upstream-port. It provides a single hotpluggable port that
will accept any PCI or PCIe device, as well as any device requiring a
pcie-*-port (the only current example of such a device is the
pcie-switch-upstream-port).

This controller can be connected only to a pcie-root-port or a
pcie-switch-downstream-port (which will be added in a later patch),
which is the reason for the new connect type
VIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides
32 ports (slot=0 to slot=31) on the downstream side, which can only
have pci controllers of model "pcie-switch-downstream-port" plugged
into them, which is the reason for the other new connect type
VIR_PCI_CONNECT_TYPE_PCIE_SWITCH.

This controller can be connected (at domain startup time only - not
hotpluggable) only to a port on the pcie root complex ("pcie-root" in
libvirt config), hence the new connect type
VIR_PCI_CONNECT_TYPE_PCIE_ROOT. It provides a hotpluggable port that
will accept any PCI or PCIe device.

New attributes must be added to the controller <target> subelement for
this - chassis and port are guest-visible option values that will be
set by libvirt with values derived from the controller's index and pci
address information.

There are some configuration options to some types of pci controllers
that are currently automatically derived from other parts of the
controller's configuration. For example, in qemu a pci-bridge
controller has an option that is called "chassis_nr"; up until now
libvirt has always set chassis_nr to the index of the pci-bridge. So
this:

  <controller type='pci' model='pci-bridge' index='2'/>

will always result in:

  -device pci-bridge,chassis_nr=2,...

on the qemu commandline. In the future we may decide there is a better
way to derive that option, but even in that case we will need for
existing domains to retain the same chassis_nr they were using in the
past - that is something that is visible to the guest so it is part of
the guest ABI and changing it would lead to problems for migrating
guests (or just guests with very picky OSes).

The <target> subelement has been added as a place to put the new
"chassisNr" attribute that will be filled in by libvirt when it
auto-generates the chassisNr; it will be saved in the config, then
reused any time the domain is started:

  <controller type='pci' model='pci-bridge' index='2'>
    <model type='pci-bridge'/>
    <target chassisNr='2'/>
  </controller>

The one oddity of all this is that if the controller configuration
is changed (for example to change the index or the pci address
where the controller is plugged in), the items in <target> will
*not* be re-generated, which might lead to conflict. I can't
really see any way around this, but fortunately if there is a
material conflict qemu will let us know and we will pass that on
to the user.

This new subelement is used in PCI controllers: the toplevel
*attribute* "model" of a controller denotes what kind of PCI
controller is being described, e.g. a "dmi-to-pci-bridge",
"pci-bridge", or "pci-root". But in the future there will be different
implementations of some of those types of PCI controllers, which
behave similarly from libvirt's point of view (and so should have the
same model), but use a different device in qemu (and present
themselves as a different piece of hardware in the guest). In an ideal
world we (i.e. "I") would have thought of that back when the pci
controllers were added, and used some sort of type/class/model
notation (where class was used in the way we are now using model, and
model was used for the actual manufacturer's model number of a
particular family of PCI controller), but that opportunity is long
past, so as an alternative, this patch allows selecting a particular
implementation of a pci controller with the "name" attribute of the
<model> subelement, e.g.:

  <controller type='pci' model='dmi-to-pci-bridge' index='1'>
    <model name='i82801b11-bridge'/>
  </controller>

In this case, "dmi-to-pci-bridge" is the kind of controller (one that
has a single PCIe port upstream, and 32 standard PCI ports downstream,
which are not hotpluggable), and the qemu device to be used to
implement this kind of controller is named "i82801b11-bridge".

Implementing the above now will allow us in the future to add a new
kind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge
device, but instead uses something else (which doesn't yet exist, but
qemu people have been discussing it), all without breaking existing
configs.

(note that for the existing "pci-bridge" type of PCI controller, both
the model attribute and <model> name are 'pci-bridge'. This is just a
coincidence, since it turns out that in this case the device name in
qemu really is a generic 'pci-bridge' rather than being the name of
some real-world chip)

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.