On IA32 host or IA32 PAE host, at present, generally, we can't create
an HVM guest with more than 2G memory, because generally it's almost
impossible for Qemu to find a large enough and consecutive virtual
address space to map an HVM guest's whole physical address space.
The attached patch fixes this issue using dynamic mapping based on
little blocks of memory.
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
contact and authentication details for the Xen-API server.
The default behaviour is still to use the existing legacy XML-RPC server.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
the domains_lock. The call itself is already locking as necessary, and it
is important for domain_start to be able to release the lock across the scope
of waitForDevices.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
x86 foreign HVM domain page mapping semantic was changed to use gmfn
instead mfn. It applies to domains with auto_translated_mode enabled,
and all ia64 domains enable auto_translated_mode. This patch changes
ia64 foreign domain page mapping to use gmfn and fixes ia64 domU buidler.
However this patch breaks domain save/restore/dump-core.
They should also be fixed-up
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
information on which keys change depending upon the numlock setting, but
this isn't being used. By forcing numlock on and off as necessary, when
receiving these keysyms through the VNC connection, we ensure that the
server's numlock status is the same as the client's.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Following on from my patch to make blktap report I/O errors back to
guest OS, a similar problem exists in the QEMU codebase. The IDE
driver never reports I/O errors during read/write operations back to
the guest OS. Instead all I/O operations are reported as
succesfull. If, for example, the host FS holding the disk image fills
up, then writes may fail due to lack of space. Since the guest OS
never sees these failures, it assumes all is well & will continue
writing. Eventually this can lead to severe & unrecoverable filesystem
corruption.
The attached patch fixes QEMU ide driver such that any failure of a
read or write operation sets the appropriate IDE status/error
registers. Having read the ATA-6 spec I think the most compliant
behaviour is to set the status register to 'READY_STAT | ERR_STAT',
and the error register to ABRT_ERR. There is already a convenience
function ide_abort_command() in the QEMU codebase which does just
this, so the attached patch simply calls that function.
With this patch the guest OS sees the I/O failure & the kernel logs
IDE errors and then retries the operation. This at least ensures that
the guest can be shutdown the out of space issue in the host corrected
and the guest restarted, without any serious filesystem damage having
occurred.
From: Daniel Berrange <berrange@redhat.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
According to Intel Spec, segments registors are cleared when exiting
virtual-8086 mode through trap or interrupts gate, so it's no need to
save their values in stack.
Signed-off-by: Xin Li <xin.b.li@intel.com>
This can be used to perform correct access checks, provide appropriate
error codes when injecting faults, and to implement an
instruction-stream prefetch cache (which is included here for HVM PTE
update emulations).
Signed-off-by: Keir Fraser <keir@xensource.com>
needs more thought, because people shouldn't need to set up their Xen-API server
to run the non-Xen-API bits of the test, and at the moment, you get
authentication failures on every SKIP.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
This patch re-adds a recently removed vTPM device handling code.
I am also removing that one code part in the test script that does not
work.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
similar to the XmTestDomain and XenDomain classes. I have wrapped the
xen-api for VM configuration creation, starting and stopping of VMs and
destruction of the VM configuration in the XenManagedDomain class's
methods. No device-related functions are provided through the class.
The managed domains' UUIDs are tracked and all created VMs are destroyed
upon failure or skipping of the test or by calling
xapi.vm_destroy_all().
I am adding a new grouptest 'xapi' for running xen-api tests.
Only caveat: I am using an empty username and password
(XmTestList/xapi.py) with Xend's authentication deactivated to run these
tests.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Use a smarter method of importing the Xen API VM struct when adding to
XendConfig.
Also add a commented __setitem__ override for XendConfig to type check
certain configuration values.
Signed-off-by: Alastair Tse <atse@xensource.com>
with I/O errors.
There are a number of flaws in the blktap userspace daemon when dealing
with I/O errors.
- The backends which use AIO check the io_events.res member to determine
if an I/O error occurred. Which is good. But when calling the callback
to signal completion of the I/O, they pass the io_events.res2 member
Now this seems fine at first glance[1]
"res is the usual result of an I/O operation: the number of bytes
transfered, or a negative error code. res2 is a second status
value which will be returned to the user"
Except that
"currently (2.6.0-test9), callers of aio_complete() within the
kernel always set res2 to zero."
And this hasn't changed anytime since 2.6.0, so by passing through
the status from 'res2', the callback thinks the I/O operation succeeded
even when it failed :-(
The fix is simple instead of passing 'res2', just pass
ep->res == io->u.c.nbytes ? 0 : 1
This would solve the error reporting to the guest, except that there
is a second flaw...
- The tapdisk I/O completion callback checks the status parameter
passed in, syslog's it and then returns. It never bothers to send
the I/O completion response back to the blktap kernel driver when
a failure occurrs.
Fortunately the fix for this is also simple. Instead of returning
from the callback when dealing with an error, we simply toggle the
status field for the pending response to BLKIF_RSP_ERROR and then
continue with the normal codepath. So the error eventually gets
back to the guest.
The scenario I used to discover the problem and test the patch is thus:
- In dom0 create a filesystem with only 200 MB of free space
- Create a 1 GB sparse file on this volume.
- Configure the guest so this sparse file appears as /dev/xvdb
- In the domU create a single partition on /dev/xvdb and format
it with ext3.
- In the DomU, mount /dev/xvdb1 on /mnt and then run
dd if=/dev/zero of=/mnt/data.bin bs=1GB count=1
Without this patch, the 'dd' command would succeed in writing 1 GB of data
even though the underlying disk in Dom0 was only 200 MB in size. More complex
tests of copying a whole directory heirarchy across resulted in catastrophic
data corruption of the filessytem itself. Manual fsck was needed to fixup
the filesystem & there were many very bad errors needing fixing.
With this patch applied the DomU sees the I/O failures and kernel logs
messages
Dec 1 11:02:53 dhcp-5-203 kernel: end_request: I/O error, dev xvdc, sector 722127
Dec 1 11:02:53 dhcp-5-203 kernel: end_request: I/O error, dev xvdc, sector 730327
Dec 1 11:02:53 dhcp-5-203 kernel: end_request: I/O error, dev xvdc, sector 738527
Dec 1 11:02:53 dhcp-5-203 kernel: end_request: I/O error, dev xvdc, sector 746727
Dec 1 11:02:53 dhcp-5-203 kernel: end_request: I/O error, dev xvdc, sector 754927
Dec 1 11:02:53 dhcp-5-203 kernel: end_request: I/O error, dev xvdc, sector 763127
Dec 1 11:02:53 dhcp-5-203 kernel: end_request: I/O error, dev xvdc, sector 771327
Dec 1 11:02:53 dhcp-5-203 kernel: end_request: I/O error, dev xvdc, sector 779527
Dec 1 11:02:53 dhcp-5-203 kernel: end_request: I/O error, dev xvdc, sector 792399
It will retry the I/O operation until it runs out of sectors to try, and then
fail the operation. The filesystem is not seriously damaged - ext3 journal
recovery will trivially cleanup if the guest is rebooted after the disk in
Dom0 is enlarged.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
[1] http://lwn.net/Articles/24366/
kfraser@localhost.localdomain
Alastair Tse
Ewan Mellor
awilliam@xenbuild2.aw
awilliam@xenbuild.aw
kaf24@localhost.localdomain
Andrew Warfield