The gdtr information in oldctx is an address for guest, not for
vmxassist. When access descriptor on guest gdt, we need to go through
guest page table if guest enable paging. This error may happen if
guest enable PE/PG in one instruction.
Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>=20
Signed-off-by: Xin Li <xin.b.li@intel.com>
and described in the user guide to demonstrate how to quickly create,
enforce, and test workload protection policies in Xen. The tool is aimed
to improve usability of sHype/ACM for Xen.It is included in a single
file to make it easy to try it out on different platforms (it inherits
the look and feel of the base platform). It is tested on Linux and
Windows. Please read the new user guide section about how to start and
use the tool (section 10.2).
Requirements: python (www.python.org), wxPython (www.wxpython.org or
try 'yum install wxPython').
Signed-off by: Reiner Sailer <sailer@us.ibm.com>
browsing the list of transaction each time
Bump the default to 10, and make it configurable through the command line.
Signed-off-by: Vincent Hanquez <vincent@xensource.com>
1. xend-pci-quirks.sxp:
Specifies which PCI device(s) may write to a set of PCI configuration
space registers. A quirky PCI device is identified by its vendor ID,
device ID, subvendor ID, and subdevice ID. If a matching entry is
found, the corresponding fields will be sent to the PCI bus manager.
Fields are composed of a register, size, and mask -- although the mask
field is currently unused.
The included policy file is for a range of tg3 devices, which is the
only type of quirky device I know about. Users with other quirky
devices are invited to either add entries to this policy file or add
an entry in the permissive file, described next. In either case, send an
email to the xen-devel list to make the device known.
2. xend-pci-permissive.sxp
Lists PCI devices that pciback should not prevent from writing to
their configuration space. This can be necessary if, for example, a new
Tigon3 devices is released with different PCI vendor/device values
such that no entry in xend-pci-quirks.sxp is triggered.
Signed-off-by: Chris Bookholt <hap10@tycho.ncsc.mil>
the corresponding fields to the PCI bus manager via sysfs nodes:
/sys/bus/pci/drivers/pciback/quirks
/sys/bus/pci/drivers/pciback/permissive
xend reads the policy file every time it creates a new domain that was
assigned a PCI device.
Signed-off-by: Chris Bookholt <hap10@tycho.ncsc.mil>
The function cpu_physical_memory_rw() thinks that if an address is
not mmio-related, it is assumed to be a RAM case. This is improper.
When making the assumption, we should make sure the address is less
than the guest physical memory size ram_size.
From: Cui, Dexuan <dexuan.cui@intel.com>
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
This adds back changes from xen-ia64-unstable.hg cset:
10570:8dc4af3f192c7c1ef3cd6921196997b903d25add
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Uninitialized ifname can cause qemu to quit. If the first character of the
ifname is not \0, qemu will think it's a valid ifname and configure
/dev/net/tun to use it. The configuration fails and qemu exits.
Based on a patch from: Steve Dobbelstein <steved@us.ibm.com>
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
The following updates are included:
- No stack allocation is necessary
- Some buggy kernels require r13 to be zeroed
- the DTB must be loaded from a fixed address, we are using
"/root/DomU.dtb" until we have the tools build the DTB on their
own.
- Though we give the PFN of the store and console pages to the new
domain we must make sure the MFN is given to the tools.
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
On xen/x86, vga bios is copied to 0xC0000 by guest firmware.
However on ia64 platform, native firmware depends on some
initialization vga state at power on and so does guest firmware.
That's why that vga bios initialization stub is required for vti
domain, to match platform requirement.
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Zhang Xiantao <xiantao.zhang@intel.com>
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
VNC client may reset color depth after connection, so if we don't
re-calculate color_table, monitor/console's background is abnormal.
Signed-off-by: Yang Xiaowei <xiaowei.yang@intel.com>
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
The root cause is that if two MMIO spaces are continuous, qemu may misuse
last MMIO space's read/write to handle current request.
Signed-off-by: Yang Xiaowei <xiaowei.yang@intel.com>
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
- add vncviewer option to qemu-dm to spawn a vncviewer process.
- add the `vncconsole' config parameter which enables qemu-dm's vncviewer
option.
Based on a patch from: Don Dugger <donald.d.dugger@intel.com>
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
