Stubdomains (and probably other domain disagregation elements too)
need to be able to tinker with another domain. This adds
XS_SET_TARGET so that XenStore allows domains to have permissions on
files on which the "target" has permissions. This also adds
xs_set_target, called by the domain builder when the 'target' option
is used in the configuration.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
Stubdomains (and probably other domain disagregation elements too)
need to be able to tinker with another domain. This adds IS_PRIV_FOR
that extends IS_PRIV by allowing domains to have privileges over a
given "target" domain. XEN_DOMCTL_set_target permits to set this
"target". A new 'target' configuration option makes the domain builder
use it.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
When the current directory is not in $PATH,
then the patch fixes the following errors:
Checking check_brctl: .: funcs.sh: not found
Checking check_crypto_lib: .: funcs.sh: not found
Checking check_curl: .: funcs.sh: not found
Checking check_iproute: .: funcs.sh: not found
Checking check_python: .: funcs.sh: not found
Checking check_python_xml: .: funcs.sh: not found
Checking check_udev: .: funcs.sh: not found
Checking check_xml2: .: funcs.sh: not found
Checking check_zlib_lib: .: funcs.sh: not found
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
I tested xm block-attach command with a wrong
parameter(file:). Naturally a command error occurred. Then I retested
xm block-attach command with a correct parameter(phy:). But a command
error occurred again. The second command error occurred because Xend
did not remove device information from self.info when the first
command error occurred.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
The new libata-eh in the Linux kernel is throwing a fit over the QEMU
cdrom device for two reasons:
1) DRQ can be set with ERR_STAT set. This is a violation of the ATAPI
state machine.
2) After a TEST_UNIT_READY ATAPI command is sent ERR_STAT is getting
set
which is correct. But, when the OS issues another ATAPI command
ERR_STAT is still set. Which is bad since the next expected command
from the OS is REQUEST_SENSE to find out why ERR_STAT is set.
bug this fixes: https://bugzilla.novell.com/show_bug.cgi?id=3D291775
Signed-off-by: Brandon Philips <bphilips@suse.de>
Porting this qemu fix to xen.
Signed-off-by: Xu Dongxiao <dongxiao.xu@intel.com>
This patch introduces tools/check/funcs.sh with some
cross-friendly abstractions, then modifies the check_*
scripts to use them.
Signed-off-by: Aron Griffis <aron@hp.com>
Pass Xen cross-compilation options through to ioemu.
Export CROSS_SYS_ROOT for use by scripts. Unexport
IOEMU_DIR since it isn't used outside of the Makefile.
Signed-off-by: Aron Griffis <aron@hp.com>
HVM-guest boot time. Also make a few PCI0 resource ResourceProducer
type -- this seems to be specified by some randomly-sampled real ACPI
systems.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
This patch adds extboot to Xen. It should be pretty harmless as the
moment because it's never enabled. extboot allows arbitrary block
devices to be used to boot guests including SCSI and PV disks. I've
tested it with both Windows and Linux guests in QEMU.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
lomount is a tool which reads and parses a partition table in a disk
image block device and then uses mount -o ...offset=... to mount it.
This is not an ideal approach. For example, if the intended
filesystem has corrupted metadata the kernel's filesystem driver may
start to write outside of the intended region. This might even be
exploitable in some perverse circumstances.
Nowadays people wanting to do this should use kpartx, which uses
devmapper to create appropriate range mappings. So lomount should be
disabled.
miniterm may well be useful but it is a clone-and-hack of an upstream
project and is currently built but not installed by default, partly
because it doesn't make sense to install on the dom0 which it might be
trying to debug.
It is probably useful to retain these two programs in the source tree
but IMO they should no longer be built by default.
The attached patch does these things:
* CONFIG_LOMOUNT and CONFIG_MINITERM in Config.mk
can enable and disable these programs
* They are disabled by default
* If CONFIG_MINITERM=y it is still built but not installed.
make -C tools/misc/miniterm install will install it.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
While wading through the patches made to Xen by OpenSUSE in their
[s]rpm, I found that they have removed various special casing for ifup
on ther distribution.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
In various places in documentation and code, IP addresses are provided
as examples, defaults, or dummy configuration. In general the
specific IP addresses used in Xen are not always appropriate. (For
example, 1.2.3.4 is used in a few places!)
The following addresses should be used:
* For examples and documentation, 192.0.2.0/24. (See RFC3330.)
* For defaults for private networks, a random network from RFC1918.
I have randomly selected 172.30.206.0/24 for this purpose and
documented this in at the only registry I know of,
www.ucam.org/cam-grin. This network should henceforth be used for
default configurations of local bridges, test networks, etc. in
Xen tools.
The following addresses should NOT be used:
* 10.0.*.*, 10.1.*.*, 192.168.0.*, 192.168.1.*, etc. Using these
addresses gives greatly increased likelihood of collision, as
ignorant network administrators and reckless middlebox vendors
often pick networks from the bottom of 10/8 and 192.168/16.
* 169.254.*.*. These are reserved for zeroconf (ad-hoc networking)
and should not be used for Xen private networks, bridges, etc.,
etc. Use of these addresses by Xen scripts causes trouble on hosts
(eg laptops) which find themselves in ad-hoc networking
environments. I think this is not hypothetical (!) since at least
one Linux distribution have specific code to detect this case and
cause Xen startup to fail iff the host already has an external
zeroconf address.
* 1.2.3.4. WTF !?
I have also used 127.0.255.255 in one place where apparently a dummy
address is needed (some Linux kernels won't accept a lack of an NFS
server address). If 127.0.255.255 is mistakenly used it is unlikely
to do any damage to real traffic even if it does escape into the
network at large.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
from special pages (ioreq, xenstore, etc). This will stop some probe
functions (e.g., embedded in memtest) from stomping on the special
pages.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
The attached patch implements a mini BIOS menu for choosing a
non-default
boot device. When a guest starts it'll display
'Press F10 to select boot device'
And wait 3 seconds, before continuing with the normal boot device. If
they press the F10 key, a menu is shown allowing a choice between
floppy, harddisk, cdrom and network (PXE).
I can't take credit for this originally - Jeremy Katz wrote it for
KVM, I merely re-diffed the patch to work against Xen's QEMU/BIOS code
tree. It has been tested in Fedora successfully against 3.1.x and 3.2.x
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
CC: Jeremy Katz <katzj@redhat.com>
If more than one boot device has been selected, the currently selected
number displayed in the menu is wrong.
Signed-off-by: Stefano Stabellini <stefano.stabellini@citrix.com>
This fixes two problems related to the SR class:
- get_PBDs() was not implemented
- get_physical_size did not work
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Fix the network-bridge logic to correctly transfer secondary IP
address from $netdev to $bridge.
e.g. if you add an secondary address/label/alias with:
$> ip addr add 172.31.0.200/24 dev eth0 label eth0:00
then, "ip addr show dev eth0" gives e.g.:
inet 172.31.0.10/24 brd 172.31.0.255 scope global eth0
inet 172.31.0.200/24 scope global secondary eth0:00
and transfer_addrs() tries to execute:
ip addr add 172.31.0.10/24 brd 172.31.0.255 scope global dev tmpbridge
ip addr add 172.31.0.200/24 scope global secondary dev tmpbridge:00
which causes the sript to fail because:
1) The device tmpbridge:00 doesn't exist
2) The "secondary" flag isn't valid
This patch fixes the sed commands to instead give:
ip addr add 172.31.0.10/24 brd 172.31.0.255 scope global dev tmpbridge label tmpbridge
ip addr add 172.31.0.200/24 scope global dev tmpbridge label tmpbridge:00
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
When using xen without a bridge but NAT or routing, HVM domains can't
boot, and qemu-dm-n.log contains:
config qemu network with xen bridge for tap0 xenbr0
bridge xenbr0 does not exist!
That's because the qemu-ifup script always tries to add the vif to
a default-named xenbr0 bridge. On the contrary, PV domains just work
fine with the same configuration file except HVM parameters.
Signed-off-by: Samuel Thibault <samuel.thibault@citrix.com>
GetCapabilityOwner function's behavior is different from that of a
real tpm device. By the difference, a TPM Manager in an HVM domain
could not detect whether TPM device has an owner or not.
Signed-off-by: Kouichi YASAKI <yasaki.kouichi@jp.fujitsu.com>
If there are a large number of kernel images configured in grub.conf
there will be too many to fit in the limited size pygrub display. This
patch fixes this so that the list of kernels scrolls as needed.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In tools/blktap/drivers/tapaio.c there is a call to read(2) whose
return value is not checked. The attached patch attempts to do
something vaguely sensible in cases of error.
Fully comprehensive error handling in this area would be quite tough
to introduce now but at least with this change when things go wrong
you stand a chance of getting some information about what happened.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Keir Fraser
Alex Williamson