* Added some constants to do with lifecycle management in XendDomain
* Added docstrings
* Made all private functions prefixed with an underscore (_)
* Added lifecycle management in XendDomain which stores configs in SXP
format.
* Added bits of XenAPI support.
* Moved all XendDomainInfo constants to a separate file
* Moved most of the domain creation login into XendDomainInfo rather
than in module level functions.
* Moved to use Xen API compatible reporting of state.
* Reorganised methods into logical groups in XendDomain and XendDomainInfo
* Moved all domain configuration validation into XendConfig
* Removed DevController cruft from the bottom of XendDomainInfo to
XendDevices.
Signed-off-by: Alastair Tse <atse@xensource.com>
* Also removed stray semicolon
* Fixed whitespace for pciif.py
* Moved DEV_MIGRATE_TEST to xen.xend.__init__.py
Signed-off-by: Alastair Tse <atse@xensource.com>
tried to a backwards memcpy across a page boundary in an MMIO region.
This should fix the problems some people have been reporting running
vim.
Signed-off-by: Steven Smith <sos22@cam.ac.uk>
If APIC=0 in VMX configuration file, VLAPIC(v) in
mov_from_cr()/mov_to_cr() will be NULL, so calling
vlapic_get_reg()/vlapic_set_reg()/vlapic_update_ppr()
would crash Xen.
Original patch from Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
AMD-V does not require the delaying of interrupt injection if the guest
IF_FLAG disallows interrupts. Remove the code in svm_intr_assist()
that was checking the guest IF in eflags.
This patch fixes the problem with HVM Windows guests, with observing a
very slow timer countdown on the initial boot menu, when there is more
than one boot option. Kbd response in this same Windows boot menu is
also acceptably responsive with this patch.
Signed-off-by: Tom Woller <thomas.woller@amd.com>=20
callback interrupt in vcpu 0. This avoids a race in SMP HVM domains
which could lead to interrupts never getting delivered. It is safe
because HVM domains always bind their event channels to vcpu 0.
Bug pointed out by Keir.
Signed-off-by: Steven Smith <sos22@cam.ac.uk>
on is level triggered rather than edge triggered, since it's a PCI device.
This is complicated by the possibility that another PCI device could be
on the same interrupt; the workaround is to have two irr registers
for the PIC and APIC, and have qemu and Xen generated interrupts go
into different ones.
This broke the alt_irq stuff. Fortunately, nobody uses that anymore, so
I've removed it.
Signed-off-by: Steven Smith <sos22@cam.ac.uk>
Also update the code in tools to create the device node if udev fails.
The tools now read the sysfs system to find the minor number needed.
Original patch from Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
With Intel VT, VMXOFF needs to be executed before halting the
CPU. Without this fix Xen or Linux is unable to start up the CPU after
a kexec reboot.
Tested using x86_32 on a Pentium D 930.
Signed-Off-By: Magnus Damm <magnus@valinux.co.jp>
The current Xen code keeps X86_CR4_VMXE set even if VMXON has not been
executed. The stop_vmx() code assumes that it is possible to call
VMXOFF if X86_CR4_VMXE is set which is not always true. Calling VMXOFF
without VMXON results in an illegal opcode trap, and to avoid this condition
this patch makes sure that X86_CR4_VMXE is only set when VMXON has
been called.
Tested using x86_32 on a Pentium D 930.
Signed-Off-By: Magnus Damm <magnus@valinux.co.jp>
blktap_poll is calling tlb_flush_all() in its main ring buffer polling
loop. This seems to be superfluous: the hypervisor should be
performing
any necessary tlb flushes on grant table operations performed by the
back-end. Even a simple memory barrier is unnecessary here as the
RING_PUSH_REQUESTS() call performs a wmb() anyway.
And tlb_flush_all() is not exported to modules, so this call prevents
blktap from building as a module. Just remove it.
Signed-off-by: Stephen Tweedie <sct@redhat.com>
tapdisk was using a 1msec select() timeout in its main event loop. On
timeout, the loop does nothing except repeat, so the timeout achieves
nothing; worse, on a machine with HZ set to less than 1000, a msec
timeout returns immediately, sending tapdisk into a 100%-CPU-
utilisation loop.
Simply remove the timeout entirely; everything still works fine, and
much more efficiently when idle.
Signed-off-by: Stephen Tweedie <sct@redhat.com>
In vmx_assist, the copy for new/old context and vmx assist magic are
all using physical address, while hvm_copy will use the virtual address.
This may cause problem when guest jump directly from real mode to
paging mode.
Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
notifications during shutdown. When rootfs goes away this can
cause the system to hang, as we notify userspace etc.
Instead we forcibly reset the state machine back to state Closed
if we are a frontend driver, to get the backend to release
resources. Necessary if we are going to kexec.
Signed-off-by: Keir Fraser <keir@xensource.com>
This patch makes blktap Do The Right Thing(TM). It allows udev to
create the /dev/xen/blktap[0-9] devices.
It creates a sysfs class called "xen". This part may later be placed
someplace else, but currently blktap is the only user so it is placed in
the blktap code.
When blktap is initialized, a blktap0 sysfs class device is made. The
other devices blktapX (X > 0) are made when the BLKTAP_IOCTL_NEWINTF
ioctl is called. This way we don't flood the sysfs and /dev/xen with
unnecessary devices.
I added a rule in the xen-backend.rules to allow for udev to create the
blktap devices.
With this, we can really remove the code to search and create the
/dev/xen/blktap[0-9]*, but I'll leave it in for now. With the use of
udev, we really should remove that code as well as the code for creating
the evtchn device. udev works for both of these now. But that removal
will have to be in another patch.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
blktap currently uses a hardcoded major of 254 for the device. This is
not robust in anyway and needs to be dynamic.
Note: it is better not to have the daemon create the node, and have udev
create it instead. But since the daemon currently creates the node
anyway, it is still the way this is done. That change needs to be made
at another time.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
If a Xen guest has a bootloader configured, then it will fail to start
on a blktap image. The problem is blkdev_uname_to_file, which cannot
parse the "tap:aio:$filename" image strings: it tries to split the
string apart at ":" and assign the result to a 2-tuple, and this
results in a python error if the split results in three or more
strings.
The fix is to split only at the first ":", and then to split again
if we detect "tap:" as the image type.
Signed-off-by: Stephen Tweedie <sct@redhat.com>
blktap is calling non-atomic kernel functions with irqs disabled, which
hits various kernel debug traps if those are enabled. The problem is
req_increase(), which takes the pending_free_lock.
This function is currently only ever called from module initialiation,
where it is impossible for it to race against anything else. Its
companion, req_decrease(), is not called at all.
Fix by removing the offending locking from req_increase() and, while
we're at it, remove req_decrease() entirely.
Signed-off-by: Stephen Tweedie <sct@redhat.com>
