The threshold register has been introduced in AMD RevF CPUs along with
SVM (Actually this MCA/MCE msr register existed before, but had no
meaning). Therefore no need for additional cpuid checks.
On read access it reports the HVM guest the register has been locked
by the BIOS. This means, it is not available for OS use. Thus, write
accesses are simply ignored. This behaviour actually matches real HW,
so guests can deal with this.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
We don't need to touch it in arch_vcpu_reset() because that's only used
to recover from a failed suspend, and the correct behaviour there is to
leave the mapping as-is.
blktapctrl already prints out exits reasons for all goto's to
open_failed except of not finding a device number for blktap0
This patch adds just that message so the user will get more info than
just "Unable to start blktapctrl"
Common source of this issue is that blktap is missing/failed to
load/...
Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
This change implements the VCPUOP_register_vcpu_info vcpu_op. This
allows a guest to choose where each VCPU's vcpu_info structure is
placed within its address space, allowing it to put it somewhere which
is easily accessible via some per-cpu data access mechanism.
When changing the mapping of the vcpu info, there's no obvious way to
prevent the other vcpus from getting a stale pointer of the vcpu_info,
which could result in them accessing bad memory (stale pointers to the
shared_info page are not a problem, because its always valid). To
avoid this, we prevent guests from changing the vcpu_info location
more than once, since there's no obvious need to allow them to do this
at this point.
(If we really want to allow guests to update the vcpu_info location
more than once, then some sort of RCU wait between updating the
pointer and performing the unmap may be the way to do it.)
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
When the global mapping cache runs out, make map_domain_page_global
return NULL on failure rather than fire an assertion failure. This
also updates the callers to handle the error gracefully.
The only exception to this is the shadow pagetable code, which uses
map_domain_page_global to create a mapping for
v->arch.paging.shadow.guest_vtable; it's not clear this needs to be a
global mapping anyway.
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
In some cases, we can end up in a vicious cycle of fatal_trap()s
within fatal_trap()s. Panic after a certain number of attempts.
Signed-off-by: Nils Nieuwejaar <nils.nieuwejaar@sun.com>
Use a per-cpu depth variable.
Signed-off-by: Keir Fraser <keir@xensource.com>
Implement a simpler interface for the hypercalls to ACM. I put the
parameters to all hypercalls into a union. On top of this I have
implemented a shim layer for enabling ACM hypercalls on PPC.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
* free memory on release
* invalidate p2m entry when unmapping grants
* check for alloc failure of idx_map
* add DONTCOPY vma flag
* hook for clearing ptes when a vma is freed by the kernel
From: Geoffrey Lefebvre <geoffrey@cs.ubc.ca>
Signed-off-by: Keir Fraser <keir@xensource.com>
mappings of the vsyscall page. This matches native behaviour by
setting the U bit on the L2-L4 page table entries and controlling
access using the L1 entries.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
stage of migration in Xend. The problem was cause by a deletion of the VM domain
ID which is used by testDevicecompleComplete ->deviceIDs->backendRoot() to get
the virtual backend device path. The virtual backend device path is used to
check if a device still exists in xenstore.
Signed-off-by: Yung Giang <yung.giang@gmail.com>
This change implements the VCPUOP_register_vcpu_info vcpu_op. This
allows a guest to choose where each VCPU's vcpu_info structure is
placed within its address space, allowing it to put it somewhere which
is easily accessible via some per-cpu data access mechanism.
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Xen-API. This also serves as a good example of the use of XML::RPC::Client
with the Xen-API.
By Ingard Mevåg <ingard [at] mevaag [dot] no>.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
ptc_ga_remote_func() might be invoked by IPI with a schedule_lock
that is acquired. (e.g., inside of vcpu_migrate())
It will cause a deadlock.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
domain builder and in to python code.
This knowledge will be useful to allow us to pre-seed the protocol
field in a VBD entry in xenstore which will allow us to run older
kernels in a 32on64 mixed environment.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
ASIDs partition the physical TLB for SVM. In the current implementation
ASIDs are used to reduce the number of TLB flushes. Each time the
guest's virtual address space changes (e.g. due to an INVLPG,
MOV-TO-{CR3, CR4} operation), instead of flushing the TLB, a new ASID is
assigned. This reduces the number of TLB flushes to at most 1/#ASIDs
(currently 1/64). The biggest advantage is that hot parts of the
hypervisor's code and data remain in the TLB.
From: Sebastian Biemueller <Sebastian.Biemueller@amd.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
- make log levels used consistent in a few places
- remove trailing newlines, dots, and commas
- remove explictly specified function names from message text
Signed-off-by: Jan Beulich <jbeulich@novell.com>
CSTAR is an unused MSR in 64-bit mode on Intel's EM64T, hence there's
no need to save/restore this MSR during context switches. Mimic real
hardware by retaining the value written for eventual guest OS reads.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Introduce a per-CPU shadow of what is currently in EFER, as context
switch code must re-write this MSR so that all guests run with
appropriate EFER.SCE and EFER.NX settings. Remove EFER from the set of
MSRs that VMX deals with in a generic fashion.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
- share more code between 32- and 64-bit variants
- properly handle continuations for 32-bit guests on 64-bit hv
- properly handle preemption (this must *not* rely on regs->eip, as
- other code may overwrite the value there by calling
- hvm_store_cpu_guest_regs()
- deny hypercall access when called from guest in vm86 mode, which
requires that ???_guest_x86_mode() make real and vm86 modes distinguishable
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Make sure MFN read from pte is valid before accessing the page info
structure associated with it. Drop guest-to-machine-physical
translation from ptwr code.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
