This introduces new attribute to filesystem element
to support customizable access mode for mount type.
Valid accessmode are: passthrough, mapped and squash.

Usage:
        <filesystem type='mount' accessmode='passthrough'>
          <source dir='/export/to/guest'/>
          <target dir='mount_tag'/>
        </filesystem>

passthrough is the default model if not specified, that's
also the current behaviour.

The following filter transition from a filter allowing incoming TCP connections

  <rule action='accept' direction='in' priority='401'>
    <tcp/>
  </rule>
  <rule action='accept' direction='out' priority='500'>
    <tcp/>
  </rule>

to one that does not allow them

  <rule action='drop' direction='in' priority='401'>
    <tcp/>
  </rule>
  <rule action='accept' direction='out' priority='500'>
    <tcp/>
  </rule>

did previously not cut off existing (ssh) connections but only prevented newly initiated ones. The attached patch allows to cut off existing connections as well, thus enforcing what the filter is showing.

I had only tested with a configuration where the physical interface is connected to the bridge where the filters are applied. This patch now also solves a filtering problem where the physical interface is not connected to the bridge, but the bridge is given an IP address and the host routes between bridge and physical interface. Here the filters drop non-allowed traffic on the outgoing side on the host.

* configure.ac (AC_INIT): Provide email and URL.

* .gnulib: Update to latest, for termios fix.
* configure.ac (AC_CHECK_HEADERS): Drop redundent check.
* bootstrap: Synchronize from upstream.
Reported by Daniel P. Berrange.

Explicitly raising a nice error in the case user tries to migrate a
guest with assigned host devices is much better than waiting for a
mysterious error with no clue for the reason.

When only some host CPUs given to cpuBaseline contain <vendor> element,
baseline CPU should not contain it. Otherwise the result would not be
compatible with the host CPUs without vendor. CPU vendors are still
taken into account when computing baseline CPU, it's just removed from
the result.

Recent CPU models were specified using invalid vendor element
<vendor>NAME</vendor>, which was silently ignored due to a bug in the
code which was parsing it.

 This patch silences the nwfilter test case.

Failure introduced in commit 3a092f38.

* tests/xml2sexprdata/xml2sexpr-boot-grub.sexpr: Fix typo.

'make -C src rpcgen' is supposed to be idempotent.  But commit
f928f43b mistakently manually edited a generated file rather
than fixing the upstream file.

* src/remote/remote_protocol.x (remote_memory_param_value): Use
correct spelling of enum values.
* src/remote/remote_protocol.c: Regenerate.

This enables support for nested SVM using the regular CPU
model/features block. If the CPU model or features include
'svm', then the '-enable-nesting' flag will be added to the
QEMU command line. Latest out of tree patches for nested
'vmx', no longer require the '-enable-nesting' flag. They
instead just look at the cpu features. Several of the models
already include svm support, but QEMU was just masking out
the svm bit silently. So this will enable SVM on such
models

* src/qemu/qemu_conf.h: flag for -enable-nesting
* src/qemu/qemu_conf.c: Use -enable-nesting if VMX or SVM are in
  the CPUID
* src/cpu/cpu.h, src/cpu/cpu.c: API to check for a named feature
* src/cpu/cpu_x86.c: x86 impl of feature check
* src/libvirt_private.syms: Add cpuHasFeature
* src/qemuhelptest.c: Add nesting flag where required

Before running each test case clear the thread local error
indicator. After running each test case, dispatch any error
that was reported

* tests/testutils.c: Fix error reporting in test suites

The TODO list changes frequently so cannot be well maintained
under GIT. Update the TODO file to point people at bugzilla
and the libvirt website

* TODO: Point at bugzilla/website

* src/xen/sexpr.c: Ensure () are escaped in sexpr2string
* tests/sexpr2xmldata/sexpr2xml-boot-grub.sexpr,
  tests/sexpr2xmldata/sexpr2xml-boot-grub.xml,
  tests/xml2sexprdata/xml2sexpr-boot-grub.sexpr,
  tests/xml2sexprdata/xml2sexpr-boot-grub.xml: Data files to
  check escaping
* tests/sexpr2xmltest.c, tests/xml2sexprtest.c: Add boot-grub
  escaping test case

 This is from a bug report and conversation on IRC where Soren reported that while a filter update is occurring on one or more VMs (due to a rule having been edited for example), a deadlock can occur when a VM referencing a filter is started.

The problem is caused by the two locking sequences of

qemu driver, qemu domain, filter             # for the VM start operation
filter, qemu_driver, qemu_domain            # for the filter update operation

that obviously don't lock in the same order. The problem is the 2nd lock sequence. Here the qemu_driver lock is being grabbed in qemu_driver:qemudVMFilterRebuild()

The following solution is based on the idea of trying to re-arrange the 2nd sequence of locks as follows:

qemu_driver, filter, qemu_driver, qemu_domain

and making the qemu driver recursively lockable so that a second lock can occur, this would then lead to the following net-locking sequence

qemu_driver, filter, qemu_domain

where the 2nd qemu_driver lock has been ( logically ) eliminated.

The 2nd part of the idea is that the sequence of locks (filter, qemu_domain) and (qemu_domain, filter) becomes interchangeable if all code paths where filter AND qemu_domain are locked have a preceding qemu_domain lock that basically blocks their concurrent execution

So, the following code paths exist towards qemu_driver:qemudVMFilterRebuild where we now want to put a qemu_driver lock in front of the filter lock.

-> nwfilterUndefine()   [ locks the filter ]
    -> virNWFilterTestUnassignDef()
        -> virNWFilterTriggerVMFilterRebuild()
            -> qemudVMFilterRebuild()

-> nwfilterDefine()
    -> virNWFilterPoolAssignDef() [ locks the filter ]
        -> virNWFilterTriggerVMFilterRebuild()
            -> qemudVMFilterRebuild()

-> nwfilterDriverReload()
    -> virNWFilterPoolLoadAllConfigs()
        ->virNWFilterPoolObjLoad()
            -> virNWFilterPoolAssignDef() [ locks the filter ]
                -> virNWFilterTriggerVMFilterRebuild()
                    -> qemudVMFilterRebuild()

-> nwfilterDriverStartup()
    -> virNWFilterPoolLoadAllConfigs()
        ->virNWFilterPoolObjLoad()
            -> virNWFilterPoolAssignDef() [ locks the filter ]
                -> virNWFilterTriggerVMFilterRebuild()
                    -> qemudVMFilterRebuild()

Qemu is not the only driver using the nwfilter driver, but also the UML driver calls into it. Therefore qemuVMFilterRebuild() can be exchanged with umlVMFilterRebuild() along with the driver lock of qemu_driver that can now be a uml_driver. Further, since UML and Qemu domains can be running on the same machine, the triggering of a rebuild of the filter can touch both types of drivers and their domains.

In the patch below I am now extending each nwfilter callback driver with functions for locking and unlocking the (VM) driver (UML, QEMU) and introduce new functions for locking all registered callback drivers and unlocking them. Then I am distributing the lock-all-cbdrivers/unlock-all-cbdrivers call into the above call paths. The last shown callpath starting with nwfilterDriverStart() is problematic since it is initialize before the Qemu and UML drives are and thus a lock in the path would result in a NULL pointer attempted to be locked -- the call to virNWFilterTriggerVMFilterRebuild() is never called, so we never lock either the qemu_driver or the uml_driver in that path. Therefore, only the first 3 paths now receive calls to lock and unlock all callback drivers. Now that the locks are distributed where it matters I can remove the qemu_driver and uml_driver lock from qemudVMFilterRebuild() and umlVMFilterRebuild() and not requiring the recursive locks.

For now I want to put this out as an RFC patch. I have tested it by 'stretching' the critical section after the define/undefine functions each lock the filter so I can (easily) concurrently execute another VM operation (suspend,start). That code is in this patch and if you want you can de-activate it. It seems to work ok and operations are being blocked while the update is being done.
I still also want to verify the other assumption above that locking filter and qemu_domain always has a preceding qemu_driver lock.

* tools/virsh.c: Update comments to match patch series.

* tools/virsh.c (vshCommandParse): Float up, to avoid the need for
a forward declaration.

This makes 'virsh --conn test:///default help help' work right;
previously, the abbreviation confused our hand-rolled option parsing.

* tools/virsh.c (vshParseArgv): Use getopt_long feature, rather
than (incorrectly) reparsing options ourselves.

"--" means no option at the following arguments.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

Some users may type command like this at the virsh shell:
virsh # somecmd 'some arg'

because they often use single quote in linux shell.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

add escaper \ for command string parsing, example:

virsh # cd /path/which/have/a/double\"quote
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

* tools/virsh.pod: Document top-level options.

Old virsh command parsing mashes all the args back into a string and
miss the quotes, this patches fix it. It is also needed for introducing
qemu-monitor-command which is very useful.

This patches uses the new vshCommandParser abstraction and adds
vshCommandArgvParse() for arguments vector, so we don't need
to mash arguments vector into a command sting.

And the usage was changed:
old:
virsh [options] [commands]

new:
virsh [options]... [<command_string>]
virsh [options]... <command> [args...]

So we still support commands like:
"define D.xml; dumpxml D" was parsed as a commands-string.

and support commands like:
we will not mash them into a string, we use new argv parser for it.

But we don't support the command like:
"define D.xml; dumpxml" was parsed as a command-name, but we have no such command-name.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

add vshCommandParser and make vshCommandParse() accept different
parsers.

the current code for parse command string is integrated as
vshCommandStringParse().
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

in old code the following commands are equivalent:
     virsh # dumpxml --update-cpu=vm1
     virsh # dumpxml --update-cpu vm1
because the old code split the option argument into 2 parts:
--update-cpu=vm1 is split into update-cpu and vm1,
and update-cpu is a boolean option, so the parser takes vm1 as another
argument, very strange.

after this patch applied, the first one will become illegal.

To achieve this, we don't parse/check options when parsing command sting,
but check options when parsing a command argument. And the argument is
not split when parsing command sting.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

the following command is allowed at shell, we also make it allowed at virsh shell.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

* tools/virsh.c (malloc, calloc, realloc, strdup): Enforce that
within this file, we use the safe vsh wrappers instead.
(cmdNodeListDevices, cmdSnapshotCreate, main): Fix violations of
this policy.

In origin code, double quote is only allowed at the begin or end
"complicated argument"
--some_opt="complicated string"  (we split this argument into 2 parts,
option and data, the data is "complicated string").

This patch makes it allow double quote at any position of
an argument:
complicated" argument"
complicated" "argument
--"some opt=complicated string"

This patch is also needed for the following patches,
the following patches will not split option argument into 2 parts,
so we have to allow double quote at any position of an argument.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

We don't fail when we can't contact HAL so we shouldn't fail if we can't
contact D-Bus either.

* include/libvirt/libvirt.h.in: some of the function type description
  were broken so they could not be automatically documented
* src/util/event.c docs/apibuild.py: event.c exports one public API
  so it needs to be scanned too, avoid a few warnings

Make use of the existing <filesystem> element to support plan9fs
filesystem passthrough in the QEMU driver

    <filesystem type='mount'>
      <source dir='/export/to/guest'/>
      <target dir='/import/from/host'/>
    </filesystem>

NB, the target is not actually a directory, it is merely a arbitrary
string tag that is exported to the guest as a hint for where to mount
it.

* docs/Makefile.am: Add todo.pl and todo.cfg-example to EXTRA_DIST

Add proper documentation to the new VIR_DOMAIN_MEMORY_* macros in
libvirt.h.in to placate apibuild.py.

Mark args as unused in for libvirt_virDomain{Get,Set}MemoryParameters
in the Python bindings and add both to the libvirtMethods array.

Update remote_protocol-structs to placate make syntax-check.

Undo unintended modifications in vboxDomainGetInfo.

Update the function table of the VirtualBox and XenAPI drivers.

The command helps to control the memory/swap parameters for the system, for
eg. hard_limit (max memory the vm can use), soft_limit (limit during memory
contention), swap_hard_limit(max swap the vm can use)

since the replacement function virStrcpy is not available

Driver interface for getting memory parameters, eg. hard_limit,
soft_limit and swap_hard_limit.

Add support in the lxc driver for various memory controllable parameters