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>
Patch allows keymap to be specified inside vfb description and
allows VM configured keymap setting to override XenD default
Signed-off-by: Pat Campbell <plc@novell.com>
While plugging a xend memory lead (c/s 18030), I introduced a bug in
the case of managed domains. Managed domains continue to exist after
shutdown and thus should not have their associated VMMetrics object
destroyed until deleted.
The bug actually manifested by a new -> start -> shutdown -> delete
sequence of operations. Shutdown destroyed the VMMetrics object and
delete tried to do the same :-):
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
1) If the device is PCIe endpoint and supports PCIe FLR, we use that;
else
2) if the device is PCIe endpoint, and all functions on the
device are assigned to the same guest, we use the immediate parent
bus's Secondary Bus Reset to reset all functions of the device (here,
actually we require all the functions of the device be assigned to the
same guest); else
3) if the device is PCI endpoint and is on a host bus
(e.g. integrated devices), and if the device supports PCI Advanced
Capabilities, we use that for FLR; else
4) we use the Secondary Bus Reset (if the PCI device is behind a
PCI/PCI-X bridge, then all devices behind the uppermost such PCI/PCI-X
bridge above this device must be co-assigned).
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
This allows domains which make buggy assumptions about the maximum
possible MFN to be worked around.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
When a domain is in the process of shutting down there is a small
window when the domain is known to XenD, but it will be unable to form
an SXPR for it due it being in the middle of device hot-unplug. This
causes the 'xm list' command to totally fail with an error like
# xm list
Error: Device 0 not connected
Usage: xm list [options] [Domain, ...]
The 'xm list' command calls into the 'domains' method of
XMLRPCServer.py in XenD. This method just iterates over the list of
domains, fetching the sxpr for each in turn, but with no exception
handling. So if a single domain fails to generate an sxpr, no data is
returned even for other domains which are still functional. This
patch simply makes XenD ignore and skip over domains which throw an
exception, logging the problematic domain.
NB, this problem only hits 'xm list' if it is configured to use the
legay XMLRPC server instead of XenAPI.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Since we only emulate the cirrus VGA video card which is only able to
expose 4MB video memory, we don't need more than that.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
Previous "xend" assumed initial Xenbus state would be "Connected" when
LUN hot-plug starts. However it was not guaranteed in general, and it
may cause some problems.
Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>
The address_bits field will be limited to 8 bits and is now embedded
in the mem_flags member, which additionally contains the node number
(limited to 8 bit).
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
If the guest provides a suspend event channel through xenstore,
xc_save will use it in preference to the old xenstore-based method.
Xend is still informed when the domain has suspended so that it can
perform device migration in parallel with last-round migration.
Signed-off-by: Brendan Cully <brendan@cs.ubc.ca>
If `hda' is used in domU config file and domain-0 has /dev/hda,
creating a domain failed by TypeError:
File "//usr/lib/python/xen/xend/server/blkif.py", line 84, in
getDeviceDetails
(device_path, devid) = blkif.blkdev_name_to_number(dev)
TypeError: unpack non-sequence
Signed-off-by: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
Rework blkdev_name_to_number to allow the tools to attach xvd disks
beyond xvdp.
1. Adds the handling for the /dev/xvd[q-z] and /dev/xvd[a-i][a-z]
extended devices
2. Changes blkdev_name_to_number() to return a tuple of (xenbus,
devnum), and then deals with the resulting fallout.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Keir Fraser