On ia64 trying to map a foreign domain page which isn't allocated
cause annoying warning message. xm dump-core results in too many
warnings. With this hook, ia64 dump-core can suprress warning.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
This indicates no machine check "units", which agrees more closely
with Xen's super-minimal machine check architecture (just enough to
allow Windows to run). This fixes a bug that occurs when migrating a
RHEL4-64bit guest to a host with fewer machine check units than the
original host. These host physical details shouldn't be leaking
through to guests.
Signed-off-by: David Lively <dlively@virtualiron.com>
has CMOV support. Leave a small amount of centaur.c around to support
that. MTRR code goes entirely, as 686-class Centaur CPUs have generic
MTRR support.
Signed-off-by: Keir Fraser <keir@xensource.com>
Don't carry dead code needlessly: this is a family 5 CPU, which Xen
doesn't support. Perhaps, other CPUs' files could use some cleanup in
that respect, too, but there it would increase the delta to the Linux
origin of these files, while here the entire file can go away.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
The TPM code in tools/ioemu/hw/tpm_tis.c has a struct containing a
number of function pointers with names open, close, read, write which
are the same as various POSIX apis already #included in the
file. POSIX allows these functions to be defined as macros and latest
GCC/glibc does indeed define them as macros depending on compiler
flags. This causes compile errors when deferencing the struct
members. The solution is either to change calls like ctx->open () to
be (* ctx->open) (), or simply to rename the struct members. Since
this struct was only used inside that one file I simply renamed them.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When I tested xm create command, I saw the following error message.
I expected an error message "Error: (12, 'Cannot allocate memory')"
because I intentionally caused a memory shortage on the test.
But the error message was different from my expectation.
# xm create /xen/HVMdomain.1
Using config file "/xen/HVMdomain.1".
Error: an integer is required
I looked at xend.log to examine the cause why the error message was
shown. (Could you see the attached xend.log?)
xend had the error message "Error: (12, 'Cannot allocate memory')"
first. But xend changed the error message to "Error: an integer is
required" halfway. I'm not sure about the cause why an exception
occurred in logging processing. But when I applied an attached patch,
I confirmed that the error message that I expected was shown. The
patch does not call xc.domain_destroy_hook() if self.domid is None.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
set_mm_mapping() may fail because of xc_domain_populate_physmap(). In
this case, we should not blindly go on; the xc_map_foreign_batch()
that follows will cause a page fault and, at best, get mapped in a
zeroed page from the dom0 (which is not what we want). While I'm in
here, fix a memory leak on an error path.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
The basic problem was that the "image" section of the sxp had a "None"
in it, which means that on the restore (either on the local machine or
remote machine), the vnc server in the qemu device model literally
needed the string "None" to properly connect. This simple patch only
puts a vncpasswd entry in the image if it is *not* None in the python
code, thus avoiding the whole issue.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Current implementation doesn't allow struct xencomm_desc::address
array to be more than single page. On IA64 it causes 64GB+ domain
creation failure. This patch generalizes xencomm to allow multipage
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
- Xencomm should check struct xencomm_desc alignment.
- Xencomm should check whether struct xencomm_desc itself (8 bytes)
doesn't cross page boundary. Otherwise a hostile guest kernel can
pass such a pointer that may across page boundary. Then xencomm
accesses an unrelated page.
- Xencomm shouldn't access struct xencomm_desc::nr_addrs multiple
times. Copy it to local area and use the copy.
Otherwise a hostile guest can modify at the same time.
- Xencomm should check whether struct xencomm_desc::address[] array
crosses page boundary. Otherwise xencomm may access unrelated pages.
- Xencomm should get_page()/put_page() after address conversion from
paddr to maddr because xen supports SMP and balloon driver.
Otherwise another vcpu may free the page at the same time.
Such a domain behaviour doesn't make sense, however nothing prevents
it.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Instrumenting thash_purge_all() shows a very low usage of vtlb
entries (21 at most).
This patch shrinks the default vtlb size from 512KB to 16KB
to optimize memory. This also speeds up ptc_e emulation.
To improve the hash function, frequency of collision never changed
and there is no performance degradation.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
Xen/powerpc runs in real mode so that it uses maddr interchangably
with vaddr. But it isn't the case in xen/ia64. It is necessary to
convert maddr to vaddr to access the page. maddr_to_virt() doesn't
convert on powerpc, so it should work on both archtechture.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
This was screwing up callers that loop on getdomaininfo(), if there
was a domain with domid DOMID_FIRST_RESERVED-1 (== DOMID_SELF-1).
They would see DOMID_SELF-1, then look up DOMID_SELF, which has domid
0 of course, and then start their domain-finding loop all over again!
Found by Kouya Shimura <kouya@jp.fujitsu.com>. Thanks!
Signed-off-by: Keir Fraser <keir@xensource.com>
