This protects critical data like
/local/domain/<domid>/console/{tty,limit}. It also means we can trust
.../vm, and hence do not need /vm_path. Various parts of the previous
two changesets disappear.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
This patch moves some dom0 variables and backend device
configuration from frontend directories to
/local/domain/<backdomid>/backend or /vm.
Also,
- /vm_path/<domid> is introduced, referencing the /vm path
- /vm_path/device/backend holds the backend device location,
rather than storing it in the frontend directory
Signed-off-by: Pascal Bouchareine <pascal@gandi.net>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
In xm start the --vncviewer option has no effect, instead -c tries to
both connect to the console and start vncviewer. Additionally, to
start vncviewer it uses the domid variable which is only defined a few
lines later. Thus xm start -c doesn't work at all.
This patch fixes both problems.
Signed-off-by: Kevin Wolf <kwolf@suse.de>
This patch will make xm return a exit code of 3 if `xm list
<non_existant_domain>` is done rather than the generic code of 1. I
used 3 because XendClient had a macro setup pointing
ERROR_INVALID_DOMAIN to 3.
From: "Shaun R." <mailinglists@unix-scripts.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Without this patch, vncviewer processes remain as follows.
This patch fixes it.
> # pgrep -fl vnc
> 4303 vncviewer -log *:stdout:0 -listen 5501
> 5089 vncviewer -log *:stdout:0 -listen 5502
> 5763 vncviewer -log *:stdout:0 -listen 5503
details:
Since 21dd1fdb73d8 there have been (as far as I can see) three
separate mechanisms for achieving a VNC display:
1. xm spawns vncviewer after getting vnc display info
from qemu-dm via xenstore (introduced in 21dd1fdb73d8)
2. xm spawns vncviewer -listen and qemu-dm connects to it
3. qemu-dm spawns vncviewer (!)
The latter two are rather strange - No.3 is very strange indeed.
So I decided that rather than try to get No.2 or No.3 on track for
going into qemu upstream, No.2 and No.3 would be dropped.
After discussion on xen-devel the mechanism No.1 was introduced,
above.
No.1 is controlled by the --spawn-vncviewer (and --vncviewer-autopass)
command line options to xm, by analogy with the -c option.
Nos.2 and 3 are controlled by elements of the domain configuration
file - and their code still remains. So if you turn all of the vnc
options on you can get several vncviewers (although only one of them
will work).
This patch removes the support for the passive connection mode No.2
After all ioemu-remote will never connect to such a vncviewer.
The options to engage this functionality were already removed from
the example config files by Keir in 18241:bf4ef45e6a38.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
- This minor patch implements the missing stub function
security_label_to_details in the dummy module. This stub function is
necessary to create domains with network interfaces for modules that
do not implement the security_label_to_details function.
Signed-off-by: George Coker <gscoker@alpha.ncsc.mil>
- This patch fixes a small casting bug in xm. The value of domid was
not returned as an int, causing commands like 'xm vncviewer domid'
to fail.
Signed-off-by: George Coker <gscoker@alpha.ncsc.mil>
There is an python indentation issue keeping the full range of syntax
for the cpuid config file parameter from working correctly. This
patch fixes that. It also fixes some misspelling and a missing 'x' in
two of the example config files (must have 32 bits represented for
cpuid registers).
Signed-off-by: Bruce Rogers <brogers@novell.com>
- The patch does away with the autogenerated xsm.py file and
introduces a config parameter in xend-config.sxp to determine the
security module. The parameter is (xsm_module_name {acm, dummy,
flask}). The default setting/option is dummy. .hgignore is also
updated to stop ignoring xsm.py on commits.
- The patch has created an xsconstant for XS_POLICY_FLASK and updated
the toolchain to check the instance of XS_POLICY_USE. XS_POLICY_USE
evalauates to XS_POLICY_FLASK or XS_POLICY_ACM or XS_POLICY_DUMMY
depending on configuration.
- Flask relies on the current value of ssidref returned by dominfo to
ensure that the label to sid mapping is consistent. ssidref had
been pop'ed from the dominfo object. The patch addresses this
issue.
- Flask python module style cleanups.
Signed-off-by: George Coker <gscoker@alpha.ncsc.mil>
This patch moves the call to XendDevices.destroy_device_state() to the
function _remove_domain. Previously only Xen-API calls were calling
the destroy_device_state() function.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
When domains are destroyed, _prepare_phantom_paths() method
and _cleanup_phantom_devs() method are called twice as follows.
destroy()@XendDomainInfo.py
_prepare_phantom_paths() --------------- 1
_cleanupVm()
destroyDomain()
_prepare_phantom_paths() ----------- 2
xc.domain_destroy_hook()
xc.domain_pause()
do_FLR()
xc.domain_destroy()
XendDomain.remove_domain()
cleanupDomain()
_cleanup_phantom_devs() ------------ 1
_cleanup_phantom_devs() ---------------- 2
XendDomain.domain_delete_by_dominfo()
This is a cleanup patch. It combines destroyDomain() method
into destroy() method, then _prepare_phantom_paths() method and
_cleanup_phantom_devs() method are called only once.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
When we "xm destroy" a guest with assigned devices, in
xen/common/domain.c:domain_kill(), we relinquish guest's memory first,
then invoke domain_destroy() -> complete_domain_destroy() ->
arch_domain_destroy() -> pci_release_devices()/iommu_domain_destroy().
Between relinquish_memory() and domain_destroy(), a device may be
issuing DMA request and access guest's relinquished memory.
We can do_FLR() to quiesce devices before xc.domain_destroy().
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
VT-d hot-plug is done in such a way: 1) xend sends 'pci-ins' command
to ioemu via xenstore; 2) ioemu creates pass-through device and raises
SCI to guest OS; guest OS loads device driver, and device driver
initializes the hot-plugged device; 3) xend does FLR. There is a race
condition about 2) and 3). If 3) runs slow, we have troubles. Thanks
for Yuji Shimada's locating the issues.
We can work around the issues by not doing FLR when we create domain
or hotplug device into guest, namely, we only do FLR when we destroy
domain or hotplug device from guest.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
On ia64, direct Linux boot is not supported, and 'Flash.fd' or
'guest_firmware.bin' has been used as a value of the 'kernel'
option. Cset:17016 ignores those strings and overrides them with
"/usr/lib/xen/boot/hvmloader".
Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com>
Signed-off-by: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
x86 IOMMU support added a lot of assumptions about what PCI buses look
like and where to find bridge devices. On ia64, we don't yet have
virtualization friendly IOMMUs, so for the moment, we just want to
keep "unsafe" PV PCI pass through working as well as it did in Xen
3.2. Looking at the code, it almost seems like x86 has thrown out
support for the old style driver domain. Things that don't
necessarily work on every PCI compliant architecture:
* You can't assume that just because there's a device at 01:01.0
that there's also a bridge at 01:00.0 and blow-up when you
don't find it. On HP ia64 boxes, PCI root bridges are not
necessarily exposed as a PCI device. This pretty much means
we can't call into any of the "FLR" code paths.
* BAR alignment: it's hard to have BAR alignment when your page
size is 16k. This wasn't a requirement for previous PV driver
domains, so I assume it's only for IOMMU support.
This is ugly, so I'm open to suggestions. It seems that all of these
architecture checks could be replaced by checking some "iommu_present"
variable to test whether the extra requirements are necessary.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
memory sizes greater than 2GB when built as a 32-bit binary.
Instead, direct HVM Linux loading approximates end of low memory via a
different method.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Latest QEMU would add a NIC device by default, unless specify the
"-nic none". So end user still get a unusable NIC even no vif in the
config file.
Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Xend doesn't start up on my laptop which has a PCI-CardBus bridge.
PCI-CardBus bridge device doesn't have a capability chain.
Also sanity checking of a capability chain.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
The new merged qemu no longer has the ability to spawn a vnc viewer
process in the bowels of the xend/qemu stack. In this patch we
provide support for this use case in a different manner - one more
akin to the mechanism used for `xm console' and `xm create -c'.
We introduce new xm options:
xm create --vncviewer [--vncviewer-autopass]
xm vncviewer [--vncviewer-autopass]
These spawn a VNC viewer, obtaining the relevant information
(including the port number and if you tell it your viewer supports it
the password to use) directly from xenstore.
Like xm console it waits in the foreground for the vnc port to become
available; the timeout case isn't handled as well as it might be - it
just causes the whole program (xm) to die with `Alarm clock' but this
is difficult to deal with given the current structure of the xs Python
lowlevel interface, which doesn't provide a timeout on the call to
wait for a xenstore watch.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Xm did not shut down domains anymore when run in xen-api mode due to a
'None' parameter being passed to xend when looking up a domain. This
fixes the problem.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
This enables the usage of a bootloader, i.e., pygrub, when starting a
domain using xm in Xen-API mode.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
devices without proper FLR capability.
Currently integrated devices without proper FLR capability are not
assignable. This is not nice since actually they may be assignable,
but due to old BIOS the proper FLR capability is not exposed. We can
use the previously-used Dstate transition method to do FLR for them.
This works well and looks few issues are reported AFAIK. Maybe we can
make a black list for the (rare) integrated devices that don't work
with this method.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Certain PCI or PCIe devices needs to be co-assigned. Currently we
require all the related devices be assigned to the same guest. This
can be relaxed to: part of them can be assgined to the same guest, and
after that, the left ones can't be assigned.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
After changeset 18030 and 18064 were checked in, I found some issues
when creating HVM domains with devices assigned.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Move the linux specific labels to osdep where they
belong. Modification on Solaris code ok'd by SUN (Ryan Scott).
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Keir Fraser