- The adjustments to README and overrides.mk are generic.
- The removal of explicit linux/config.h inclusion should also not
cause any issues.
- The introduction of irq_handler_t should eliminiate warnings on
2.6.19+ kernels (I didn't check they're there, but since the
request_irq prototype changed, I'm sure there's at least
one. However, as a result changes to the Linux tree are expected to
be required.
- The change setup_xen_features -> xen_setup_features follows the
naming in mainline 2.6.23 but would apparently also require changes
to the Linux tree.
- The changes SA_* -> IRQF_ and pci_module_init ->
pci_register_driver should also not cause issues.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
This patch writes a field /local/vm/DOMID/console/type taking the
value 'ioemu' or 'xenconsoled'. If xenconsoled sees a type that is
not its own, then it skips handling of that guest. The qemu-dm
process doesn't need to read this field since it will only attach
to the console if given the -serial pty arg which XenD already
ensures matches this xenstore field.
The overall behaviour is that if a paravirt guest has a qemu-dm
process running then that handles the console, otherwise the
xenconsoled handles it. The former is more functional, with the
exception of not currently supporting persistent logging to a
file at the same time as exposing a PTY.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patches adapts XenD so that it is capable of starting a qemu-dm
device model for both paravirt and fullyvirt guests. A paravirt guest
will only be given a device model if it has a VFB configured, or the
user explicitly include the device_model option in the config
config. This avoids unnecessary overhead for those wanting a minimal
paravirt guest.
The bulk of this patch involves moving code from the HVMImageHandler
into the base ImageHandler class. The HVMImageHandler and
LinuxImageHandler subclasses now merely containing a couple of
overrides to set some specific command line flags. The most important
is -M xenpv, vs -M xenfv.
The XenConfig class has a minor refactoring to add a has_rfb() method
to avoid duplicating code in a couple of places. Instead of hardcoding
DEFAULT_DM it now uses the xen.util.auxbin APIs to locate it - this
works on platforms where qemu-dm is in /usr/lib64 instead of
/usr/lib. As before paravirt only gets a default qemu-dm if using a
VFB.
The vfbif.py class is trimmed out since it no longer needs to spawn a
daemon. A few other misc fixes deal with qemu-dm interactions when
saving/restoring, and in particular recovering from save failures (or
checkpointing).
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch adds a paravirt console driver to qemu-dm. This is used
when the QEMU machine type is 'xenpv', connecting to the ring buffer
provided by the guest kernel. The '-serial' command line flag controls
how the guest console is exposed.
For parity with xenconsoled the '-serial pty' arg can be used. For
guests which are running a qemu-dm device model, the xenconsoled
daemon is no longer needed for guest consoles. The code for the
xen_console.c is based on the original code in
tools/console/daemon/io.c, but simplified; since its only dealing with
a single guest there's no state tracking to worry about.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch re-factors the paravirt console xenfb_attach_dom
method. The original method blocks the caller until the front &
backends have both switched to the connected state. This isn't an
immediate problem, but patches which follow will extend qemu to also
handle the text console so blocking on graphics console startup will
block the text console processing.
The new code is basically a state machine. It starts off with a watch
waiting for the KBD backend to switch to 'initialized' mode, then does
the same for the FB backend. Now it waits for KBD & FB frontend
devices to initialize, reading & mapping the framebuffer & its config
at the appropriate step. When the KBD frontend finally reaches the
connected state it registers a graphical console with QEMU and sets up
the various framebuffer, mouse & keyboard event handlers. If a client
connects to the VNC server before this is completed, then they will
merely see a text console (or perhaps the monitor if configured that
way).
The main difference from previous versions of this patch, is that at
the suggestion of Markus Armbruster, I'vere-ordered the individual
static functions so they are in order-of-call, rather than
reversed. Although I now have to pre-declare them, it is much easier
to read the code. I have also fixed the keycode -> keysym translations
to match previous behaviour.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch merges the public & private structs from the paravirt FB
into a single struct. Since QEMU is the only consumer of this code
there is no need for the artifical pub/priv split. Merging the two
will make it possible to more tightly integrate with QEMU's event
loop and do asynchronous non-blocking negoiation with the frontend
devices (see next patch).
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch moves a bunch of code out of the xen_machine_pv.c file and
into the xenfb.c file. This is simply a re-factoring to facilitate the
two patches which follow.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch is a simple code re-factoring to move the event loop
integration directly into the xenfb.c file. It is to facilitate
the patches which follow.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch removes all trace of the standalone paravirt framebuffer
daemon. With this there is no longer any requirement for
LibVNCServer. Everything is handled by the QEMU device model. The
xenfb.c and xenfb.h files are now moved (without code change) into
tools/ioemu/hw/ & the temporary Makefile hack from the previous patch
is removed.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch adds a paravirt machine type to QEMU. This can be requested
by passing the arg '-M xenpv' to qemu-dm. Aside from -d, and
-domain-name, the only other args that are processed are the VNC / SDL
graphics related args. Any others will be ignored. A tweak to
helper2.c was made to stop it setting up a file handler watch when
there are no CPUs registered.
The paravirt machine is in hw/xen_machine_pv.c and registers an
instance of the xenfb class, integrating it with the QEMU event loop
and key/mouse handlers. A couple of methods were adding to xenfb.h to
allow direct access to the file handles for xenstore & the event
channel.
The vfbif.py device controller is modified to launch qemu-dm instead
of the old xen-vncfb / sdlfb daemons.
When receiving framebuffer updates from the guest, the update has to
be copied into QEMU's copy of the framebuffer. This is because QEMU
stores the framebuffer in the format that is native to the SDL
display, or VNC client. This is not neccessarily the same as the guest
framebuffer which is always 32bpp. If there is an exact depth match we
use memcpy for speed, but in the non-matching case we have to fallback
to slow code to convert pixel formats. It fully supports all features
of the paravirt framebuffer including the choice between absolute &
relative pointers. The overall VIRT memory image size is about same as
old xen-vncfb, but the resident memory size is a little increased due
to copy of the framebuffer & some QEMU static state overhead. Most of
this is shared across QEMU processes.
To avoid both moving the xenfb.c and making changes to it in the same
patch, this just uses a Makefile hack to link against the xenfb.o from
the tools/xenfb/ directory. This will be removed in the following
patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch does a (no functional change) re-arrangement of the code
for starting up a fully virtualized guest. In particular it creates a
new QEMU machine type for Xen fullyvirt guests which can be specified
with '-M xenfv'. For compatibility this is in fact made to be the
default. The code for setting up memory maps is moved out of vl.c, and
into hw/xen_machine_fv.c. This is basically to ensure that it can be
easily skipped when we add a paravirt machine type in the next patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
BIOSes clobber GDTR. While we're here reset IDTR too, although it's
not really necessary.
Signed-off-by: John Byrne <john.l.byrne@hp.com>
Sigend-off-by: Keir Fraser <keir@xensource.com>
docs/misc/vtd.txt is a vt-d how-to document that should answer
questions about how to use vt-d with latest Xen.
Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Check that the policy is of type ACM and return an error if it is not.
Reworked the way the label of a domain is read.
Signed-off-by; Stefan Berger <stefanb@us.ibm.com>
Put the __UNLABELED__ label into the mapfile if policy specifies this
label rather than keeping the NULL_LABEL there. Also lock the map file
when it's rewritten and propagate the return code from compiling the
policy to callers.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Rather than picking up the current policy from the managed policies
file the hypervisor is asked for the name of the current policy.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
- recently I added an other_config field to the VTPM record which now
needs to be accounted for otherwise the test determines a bad key
- the dry-run command was throwing a different type of exception
(ACMError) than what was caught (XSMError)
- the tests based on the raw Xen-API need to build the PV_args
parameters from the old 'root' and 'extra' parameters.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Looking at the Linux patch as an example, it adds more code and
complexity than it removes, for no obvious performance benefit.
Signed-off-by: Keir Fraser <keir@xensource.com>
Prevent softlock up when VTi domain destruction by making
relinquish_memory() continuable. It was assumed that
mm_teardown() frees most of page_list so that the list which
is passed to relinquish_memory() is short. However the
assumption isn't true for VTi domain case because qemu-dm
maps all the domain pages. To avoid softlock up message,
make relinquish_memory() continuable.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
guests. Use this to pin virtual framebuffer VRAM as attribute WB, even
if guest tries to map with other attributes.
Signed-off-by: Disheng Su <disheng.su@intel.com>
The xenbaked daemon and xenmon utility communicate via a mmap'ed
shared file. Since this file is located in /tmp, unprivileged users
can cause arbitrary files to be truncated by creating a symlink from
the well-known /tmp filename to e.g., /etc/passwd.
The fix is to place the shared file in a directory to which only root
should have access (in this case /var/run/).
This bug was reported, and the fix suggested, by Steve Kemp
<skx@debian.org>. Thanks!
Signed-off-by: Keir Fraser <keir@xensource.com>
* use memory 0x8c000-0x90000 to avoid trampling the area above
0x90000 -- some bootloaders may leave droppings in that region
* reserve 2kB for vga mode table -- limit of 128 VESA modes could
overflow the original 1kB allocation
* remove unnecessary alignment of trampoline GDT
We should do clean before read operation. Otherwise, read one byte
data may get garbage data sometimes.
Signed-off-by: Zhang Xin <xing.z.zhang@intel.com>
Don't share privregs with hvm domain and twist IA64 xen dump core format
slightly. Xen shares privregs pages with IA64 HVM domain for xm dump-core
to dump the pages. However sharing the page allows hvm guest domain
peek/destroy the page contents that might cause xen crash. And the xen
dump core file doesn't need privregs page because cpu context should be
obtained from vcpu context in case of IA64 HVM domain.
Although this patch modify xen dump core format, current crash utility
(at least crash 4.0-4.7) doesn't look into .xen_ia64_mmapped_regs section
and I don't know any other tools to understand xen dump core file.
So this format modification doesn't cause incompatibility issue.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
xen_core_regs, as passed by kexec_crash_save_info(), is 32-bit aligned as
it is the data section of an ELF-note. In order to ensure 64-bit aligned
access when xen_core_regs is filled in, shift it a bit and then memmove()
the data back into the 32-bit aligned location after the values have been
written.
Without this change kdump panics on an unaligned-access.
Signed-off-by: Simon Horman <horms@verge.net.au>
Keir Fraser
Tim Deegan
Alex Williamson