So far our code is full of the following pattern:

  dom = virGetDomain(conn, name, uuid)
  if (dom)
      dom->id = 42;

There is no reasong why it couldn't be just:

  dom = virGetDomain(conn, name, uuid, id);

After all, client domain representation consists of tuple (name,
uuid, id).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There is no "node driver" as there was before, drivers have to do
their own ACL checking anyway, so they all specify their functions and
nodeinfo is basically just extending conf/capablities.  Hence moving
the code to src/conf/ is the right way to go.

Also that way we can de-duplicate some code that is in virsysfs and/or
virhostcpu that got duplicated during the virhostcpu.c split.  And
Some cleanup is done throughout the changes, like adding the vir*
prefix etc.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

There is no reason for it not to be in the utils, all global symbols
under that file already have prefix vir* and there is no reason for it
to be part of DRIVER_SOURCES because that is just a leftover from
older days (pre-driver modules era, I believe).
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Both QEMU and bhyve are using the same function for setting up the CPU
in virCapabilities, so de-duplicate it, save code and time, and help
other drivers adopt it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Along with video and VNC support, bhyve has introduced USB tablet
support as an input device. This tablet is exposed to a guest
as a device on an XHCI controller.

At present, tablet is the only supported device on the XHCI controller
in bhyve, so to make things simple, it's allowed to only have a
single XHCI controller with a single tablet device.

In detail, this commit:

 - Introduces a new capability bit for XHCI support in bhyve
 - Adds an XHCI controller and tabled support with 1:1 mapping
   between them
 - Adds a couple of unit tests

There are a number of functions in bhyve_capabilities.c that probe
hypervisor capabilities by executing the bhyve(1) binary with the
specific device arugment, checking error message (if any) and setting
proper capability bit. As those are extremely similar, move this logic
into a helper function and convert existing functions to use that.

 * Extract filling bhyve capabilities from virBhyveDomainCapsBuild()
   into a new function virBhyveDomainCapsFill() to make testing
   easier by not having to mock firmware directory listing and
   hypervisor capabilities probing
 * Also, just presence of the firmware files is not sufficient
   to enable os.loader.supported, hypervisor should support UEFI
   boot too
 * Add tests to domaincapstest for the main caps possible flows:
    - when UEFI bootrom is supported
    - when video (fbus) is supported
    - neither of above is supported

Introduce config file support for the bhyve driver. The only available
setting at present is 'firmware_dir' for specifying a directory with
UEFI firmware files.

When creating host CPU definition usable with a given emulator, the CPU
should not be defined using an unsupported CPU model. The new @models
and @nmodels parameters can be used to limit CPU models which can be
used in the result.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The parameter can be used to request either VIR_CPU_TYPE_HOST (which has
been assumed so far) or VIR_CPU_TYPE_GUEST definition.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

cpuNodeData has always been followed by cpuDecode as no hypervisor
driver is really interested in raw CPUID data for a host CPU. Let's
create a new CPU driver API which returns virCPUDefPtr directly.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

bhyve supports 'gop' video device that allows clients to connect
to VMs using VNC clients. This commit adds support for that to
the bhyve driver:

 - Introducr 'gop' video device type
 - Add capabilities probing for the 'fbuf' device that's
   responsible for graphics
 - Update command builder routines to let users configure
   domain's VNC via gop graphics.
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>

Extend domain capabilities XML with the information about
available UEFI firmware files. It searches in the location
that the sysutils/bhyve-firmware FreeBSD port installs
files to.
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>

Allow to boot using UEFI rather than using an external boot loader
such as bhyveload or grub-bhyve.

Also, make LPC PCI-ISA bridge handling more flexible as now it's
needed not only for serial ports, but for bootrom as well.
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>

Implement the BHACE_CAP_LPC_BOOTROM capability by checking the stderr
output of 'bhyve -l bootrom'. If the bootrom option is unsupported, this
will contain the following output:

    bhyve: invalid lpc device configuration 'bootrom'

On newer bhyve versions that do support specifying a bootrom image, the
standard help will be printed.

The new API is called virCPUDataFree. Individual CPU drivers are no
longer required to implement their own freeing function unless they need
to free architecture specific data from virCPUData.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Recently e1000 NIC support was added to bhyve; implement that in
the bhyve driver:

 - Add capability check by analyzing output of the 'bhyve -s 0,e1000'
   command
 - Modify bhyveBuildNetArgStr() to support e1000 and also pass
   virConnectPtr so it could call bhyveDriverGetCaps() to check if this
   NIC is supported
 - Modify command parsing code to add support for e1000 and adjust tests
 - Add net-e1000 test

virNetDevTapCreateInBridgePort() has always set the new tap device to
the current MTU of the bridge it's being attached to. There is one
case where we will want to set the new tap device to a different
(usually larger) MTU - if that's done with the very first device added
to the bridge, the bridge's MTU will be set to the device's MTU. This
patch allows for that possibility by adding "int mtu" to the arg list
for virNetDevTapCreateInBridgePort(), but all callers are sending -1,
so it doesn't yet have any effect.

Since the requested MTU isn't necessarily what is used in the end (for
example, if there is no MTU requested, the tap device will be set to
the current MTU of the bridge), and the hypervisor may want to know
the actual MTU used, we also return the actual MTU to the caller (if
actualMTU is non-NULL).

Like it usually happens, I fixed one thing and broke another:
in 803966c7 address allocation was fixed for SATA disks, but
broke that for virtio disks, because it dropped disk address
assignment completely. It's not needed for SATA disks anymore,
but still needed for the virtio ones.

Bring that back and add a couple of tests to make sure it won't
happen again.

As bhyve for a long time didn't have a notion of the explicit SATA
controller and created a controller for each drive, the bhyve driver
in libvirt acted in a similar way and didn't care about the SATA
controllers and assigned PCI addresses to drives directly, as
the generated command will look like this anyway:

 2:0,ahci-hd,somedisk.img

This no longer makes sense because:

 1. After commit c07d1c1c it's not possible to assign
    PCI addresses to disks
 2. Bhyve now supports multiple disk drives for a controller,
    so it's going away from 1:1 controller:disk mapping, so
    the controller object starts to make more sense now

So, this patch does the following:

 - Assign PCI address to SATA controllers (previously we didn't do this)
 - Assign disk addresses instead of PCI addresses for disks. Now, when
   building a bhyve command, we take PCI address not from the disk
   itself but from its controller
 - Assign addresses at XML parsing time using the
   assignAddressesCallback. This is done mainly for being able to
   verify address allocation via xml2xml tests
 - Adjust existing bhyvexml2{xml,argv} tests to chase the new
   address allocation

This patch is largely based on work of Fabian Freyer.

Add virBhyveDriverCreateXMLConf, a simple wrapper around
virDomainXMLOptionNew that makes it easier to pass bhyveConnPtr
as a private data for parser. It will be used later for device
address allocation at parsing time.

Update consumers to use it instead of direct calls to
virDomainXMLOptionNew.

As we now have proper callbacks connected for the tests, update
test files accordingly to include the automatically generated
PCI root controller.

Introduce a BHYVE_CAP_AHCI32SLOT capability that shows
if 32 devices per SATA controller are supported, and
a bhyveProbeCapsAHCI32Slot function that probes it.

When generating a domain XML from native command (i.e. via
the connectDomainXMLFromNative call), we should use
interface type 'bridge' rather than 'ethernet' because we only
support bridges at this point.

As we don't have bridge name explicitly specified on the command line,
just use 'virbr0' as a default.

This function doesn't actually reserve an entire slot any more, it
reserves a single PCI address, so this name is more appropriate.

Since we don't actually reserve an entire slot at a time anymore, the
name of this function is just confusing, and it's almost identical in
operation to virDomainPCIAddressReserveNextAddr() anyway, so remove
the *Slot() function and replace calls to it with calls to *Addr(...,
-1).

When changing the metadata via virDomainSetMetadata, we now
emit an event to notify the app of changes. This is useful
when co-ordinating different applications read/write of
custom metadata.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We have couple of functions that operate over NULL terminated
lits of strings. However, our naming sucks:

virStringJoin
virStringFreeList
virStringFreeListCount
virStringArrayHasString
virStringGetFirstWithPrefix

We can do better:

virStringListJoin
virStringListFree
virStringListFreeCount
virStringListHasString
virStringListGetFirstWithPrefix
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

New line character in name of domain is now forbidden because it
mess virsh output and can be confusing for users.
Validation of name is done in drivers, after parsing XML to avoid
problems with dissappeared domains which was already created with
new-line char in name.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Use 'goto cleanup'-style error handling instead of explicitly
freeing variables in every error path.

Change the virDomainChrDef to use a pointer to 'source' and allocate
that pointer during virDomainChrDefNew.

This has tremendous "fallout" in the rest of the code which mainly
has to change source.$field to source->$field.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit id '5f2a1327' missed this one.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This function for some weird reason returns integer instead of
virDomainNetType type. It is important to return the correct type
so that we know what values we can expect.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This way we get reference counting and we can get rid of locking
function.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

In commit 7f127ded cpuCompareXML was renamed to virCPUCompareXML,
so change the bhyve driver to use the new function and thus
fix the build.

Just like virDomainDefPostParseCallback has gained new
parseOpaque argument, we need to follow the logic with
virDomainDeviceDefPostParse.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParse and subsequently virDomainDefParseNode too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some callers might want to pass yet another pointer to opaque
data to post parse callbacks. The driver generic one is not
enough because two threads executing post parse callback might
want to see different data (e.g. domain object pointer that
domain def belongs to).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

As bhyve currently doesn't use controller addressing and simply
uses 1 implicit controller for 1 disk device, the scheme looks the
following:

 pci addrees -> (implicit controller) -> disk device

So in fact we identify disk devices by pci address of implicit
controller and just pass it this way to bhyve in a form:

 -s pci_addr,ahci-(cd|hd),/path/to/disk

Therefore, we cannot use virDeviceInfoPCIAddressWanted() because it
does not expect that disk devices might need PCI address assignment.

As a result, if a disk was specified without address, it will not be
generated and domain will to start.

Until proper controller addressing is implemented in the bhyve
driver, force each disk to have PCI address generated if it was not
specified by user.

Allow to store driver specific data on a per-vcpu basis.

Move of the virDomainDef*Vcpus* functions was necessary as
virDomainXMLOptionPtr was declared below this block and I didn't want to
split the function headers.