blktap2 devices must be handled differently than blktap2
devices. blktap2 devices require a sysfs write to close the underlying
device, as well as extra sysfs writes when the domU is
paused/unpaused. The differences between blktap1 and blktap2 are great
enough to warrant the creation of a new device class, 'tap2', and
device controller for blktap2 devices.
* add a new device controller (Blktap2Controller) and device class
(tap2) for blktap2 devices
* move blktap2 specific code from DevController to Blktap2Controller
* if possible, check xenstore to determine block device class
* use vmpath (/vm/<uuid>/) when releasing devices
* modify linux hotplug cleanup script to handle blktap2 device
removal
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
* Change default settings to relative pathes.
* Make xend to prepend install directory if entries have no absolute
* path
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
This patch changes fs-backend to use /var/lib/xen as default export
and check all the file names and paths given by the frontend against the
export path, so that the frontend can only operate under the export
directory.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This is an alternative to identity mapping virtual functions.
It works by assigning the numerically lowest virtual function that is
available.
* The order of assignment is thus dependent on the order that physical
functions are specified.
e.g.
config physical virtual
01.00.0,2 -> 01:00.0 -> 00:07.0
-> 01:00.2 -> 00:07.1
is different to
config physical virtual
01.00.2,0 -> 01:00.2 -> 00:07.0
-> 01:00.0 -> 00:07.1
* Physical function 0 need not be present
e.g.
config physical virtual
01.00.1,2 -> 01:00.1 -> 00:07.0
-> 01:00.2 -> 00:07.1
* Functions from the same physical multi-function device
may be exported as multiple multi-function and single-function
devices
e.g.
01.00.0,2 -> 01:00.0 -> 00:07.0
-> 01:00.2 -> 00:07.1
and
01.00.1,3 -> 01:00.1 -> 00:08.1
-> 01:00.3 -> 00:08.1
and
01.00.5 -> 01:00.5 -> 00:09.0
Cc: Dexuan Cui <dexuan.cui@intel.com>
Cc: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Hook things up to allow multi-function pass-through.
This includes making sure that request is valid.
In the case of pci-detach:
* All the functions requested must be attached to the same virtual
slot * and;
* A request must include the functions attached to a virtual slot
Cc: Dexuan Cui <dexuan.cui@intel.com>
Cc: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
When unplugging a function, all functions in the same vslot must be
unplugged, and function 0 must be one of the functions present when a
vslot is hot-plugged. Telling qemu-dm to unplug function 0 also tells
it to unplug all other functions in the same vslot.
Cc: Dexuan Cui <dexuan.cui@intel.com>
Cc: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
The general format is as follows:
Now: SEQ:BUS:DEV.FUNC[@VSLOT][,OPT...]
New: SEQ:BUS:DEV.FUNC0-FUNCN[@VSLOT][,OPT...]
SEQ:BUS:DEV.FUNC0,FUNCM,FUNCN[@VSLOT][,OPT...]
SEQ:BUS:DEV.*[@VSLOT][,OPT...]
In the case of unplug the VSLOT and OPT must be omitted.
Xm expands this notation notation out and passes
more conventional parameters to qemu-xen.
E.g:
0000:00:01.00-03 becomes:
0000:00:01.00
0000:00:01.01
0000:00:01.02
0000:00:01.03
0000:00:01.00,03,05,07 becomes:
0000:00:01.00
0000:00:01.03
0000:00:01.05
0000:00:01.07
For a device that has functions 0, 1, 2, 3, 5 and 7,
0000:00:01.* becomes:
0000:00:01.00
0000:00:01.01
0000:00:01.02
0000:00:01.03
0000:00:01.05
0000:00:01.07
Cc: Dexuan Cui <dexuan.cui@intel.com>
Cc: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Cc: Akio Takebe <takebe_akio@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Instead of suppling a slot number to qemu-xen, supply a devfn.
This and subsequent other changes will allow xend to ask
for more than one function to be inserted into a single slot -
by specifying which function of the slot should be used.
This is a minimal patch for this change. A subsequent
patch that has a lot of noise to rename slot to devfn
is intended to follow.
Cc: Dexuan Cui <dexuan.cui@intel.com>
Cc: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Ubuntu puts /var/lock on tmpfs, so we should create /var/lock at
startup, rather than at installation time.
Signed-off-by: Jun Koi <junkoi2004@gmail.com>
udev removed the udevinfo symlink from versions higher than 123 and
xen's build-system could not detect if udev is in place and has the
required version.
Signed-off-by: Marc-A. Dahlhaus <mad@wol.de>
X.org is installed in /usr/X11R7.
Attached patch covers this in the x11 check.
Xen has no direct X11 dependency
(it's inherited from SDL and SDL is optional for qemu-dm)
so warn but don't fail if no X11 is installed.
Fixes build problem on distributions which build their packages (*BSD
and Gentoo).
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
- Have the buid system generate a file which exports the install paths
for the hotplug scripts and stubdom / stubdom-dm
- Move file generation code from tools/python/Makefile into a gmake
macro
in Config.mk to avoid maintenance of three duplicates each with its
own
tweaks and bugs
- Export gmake variables into ioemu as shell variables
for upcoming ioemu patches
- Do above as a gmake macro to avoid maintenance of several duplicates
- Adjust hotplug scripts to find the right xen binaries from the
install directory
- Adjust stubdom-dm to use the install directories
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
- Use standard off_t and lseek() instead of non-portable off64_t and
lseek64()
- Use uuid API as documented in DCE 1.1 RPC specification
- Add NetBSD implementation for blk_getimagesize() and
blk_getsectorsize()
- Use blk_getimagesize() and blk_getsectorsize()
- Fix uuid header check
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
When we want to setup a bridge without a ip address, function
do_ifup will not activate the bridge.
We should make the bridge active, then vif-bridge can work on the
bridge.
Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
The first start of a managed domain succeeds. But the second
start of the managed domain fails as follows. The problem occurs
when tapdisks are given to the managed domain. I think that the
problem occurs because the uname of tapdisks is overwritten with
"phy:/dev/xen/tadisk-2/tapdev*".
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Using changeset 19791:c0d2838fc10f, I can't create an HVM.
xend.log shows:
File "usr/lib64/python2.4/site-packages/xen/xend/image.py", line
759, in configure
store_dmargs.remove('-sdl')
ValueError: list.remove(x): x not in list
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
Reset BlktapController's device class back to 'tap' once the device
has been created. This fixes save/restore for VMs with blktap2 disks.
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
Signed-off-by: Dutch Meyer <dmeyer@cs.ubc.ca>
This patch re-enables a useful blktap1 for users who disable blktap2.
Itremoves tapdisk and blktapctrl from blktap2, both of which cause
problems with blktap operation. In addition, this patch modifies xend
to check for blktap2 installation. If the blktap2 driver isn't
running (hopefully because the dom0 kernel option wasn't selected) we
fall back to blktap.
Signed-off-by: Dutch Meyer <dmeyer@cs.ubc.ca>
Add support for the qemu monitor in a stubdom, the same way the
emulated serial support was added few days ago. The stubdom exports
the monitor as a pty and minios opens a console frontend; qemu in dom0
provides the correspondent backend for this additional pv console that
happens to be the qemu monitor.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Using changeset 19783: 61ec78692b13, device assignment can't work:
e.g., in find_the_uppermost_pci_bridge(),
parent = dev_parent.find_parent()
...
dev_parent = PciDevice(parent),
we can see parent['domain'] is int and in PciDevice's __init__,
int(dev['domain'], 16) would fail:
TypeError: int() can't convert non-string with explicit base
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Since the shared info layout is fixed, guests are required to use
VCPUOP_register_vcpu_info prior to booting any vCPU beyond the
traditional limit of 32.
MAX_VIRT_CPUS, being an implemetation detail of the hypervisor, is no
longer being exposed in the public headers.
The tools changes are clearly incomplete (and done only so things
would
build again), and the current state of the tools (using scalar
variables all over the place to represent vCPU bitmaps) very likely
doesn't permit booting DomU-s with more than the traditional number of
vCPU-s. Testing of the extended functionality was done with Dom0 (96
vCPU-s, as well as 128 vCPU-s out of which the kernel elected - by way
of a simple kernel side patch - to use only some, resulting in a
sparse
bitmap).
ia64 changes only to make things build, and build-tested only (and the
tools part only as far as the build would go without encountering
unrelated problems in the blktap code).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
There seems to be little need to use the domain, bus, slot and
function to look up the virtual slot to pass as the argument to
hvm_destroyPCIDevice(), only to have hvm_destroyPCIDevice() use the
virtual slot for the sole purpose of looking up the domain, bus, slot
and function.
Signed-off-by: Simon Horman <horms@verge.net.au>
Keir Fraser