On Thu, Dec 08, 2011 at 12:52:19PM +0100, Jan Kiszka wrote:
Changes in v4:
- rebased of current uq/master
- fixed stupid bugs that broke bisectability and user space irqchip mode
- integrated NMI-over-LINT1 injection logic
CC: Lai Jiangshan la...@cn.fujitsu.com
Jan Kiszka (15):
msi:
On 2011-12-12 17:37, Marcelo Tosatti wrote:
On Thu, Dec 08, 2011 at 12:52:19PM +0100, Jan Kiszka wrote:
Changes in v4:
- rebased of current uq/master
- fixed stupid bugs that broke bisectability and user space irqchip mode
- integrated NMI-over-LINT1 injection logic
CC: Lai Jiangshan
* Sasha Levin levinsasha...@gmail.com wrote:
+ kvm-bz_start = mmap(NULL, kvm-bz_len, PROT_READ | PROT_WRITE,
+ MAP_PRIVATE, kvm-bz_fd, setup_end);
+ /* NOP everything before the kernel start */
+ memset(kvm-bz_start, 0x90, setup_size - setup_end);
On Mon, Dec 12, 2011 at 07:47:35PM +0200, Sasha Levin wrote:
Another usecase which I've only first heard about couple of days ago is
loading extremely large bzImages. Those images are 300MB+ in size and
come with built in filesystem. Apparently it's some sort of a livecd
variant.
Having a
On 12/09/2011 05:15 PM, Alexander Graf wrote:
On 09.12.2011, at 20:15, Scott Wood wrote:
On 12/09/2011 01:10 PM, Alexander Graf wrote:
On 09.12.2011, at 19:19, Scott Wood scottw...@freescale.com wrote:
On 12/09/2011 09:26 AM, Alexander Graf wrote:
Our vcpu kick implementation differs a
On 12/12/2011 06:51 PM, Jan Kiszka wrote:
Any thoughts on the qemu-kvm merge plan? Sounds painful.
Pain will be where the existing qemu-kvm extensions collide with these
refactored upstream devices (backend/frontend split specifically).
That's where we have to merge very carefully.
On Mon, Dec 12, 2011 at 9:30 AM, Avi Kivity a...@redhat.com wrote:
On 12/11/2011 12:25 PM, Christoffer Dall wrote:
In order to support KVM on a SMP host, it is necessary to initialize the
hypervisor on all CPUs, mostly by making sure each CPU gets its own
hypervisor stack and runs the HYP init
On Mon, Dec 12, 2011 at 9:32 AM, Avi Kivity a...@redhat.com wrote:
On 12/11/2011 12:25 PM, Christoffer Dall wrote:
From: Marc Zyngier marc.zyng...@arm.com
A guest may need to know which CPU it has booted on (and Linux does).
Now that we can run KVM on a SMP host, QEMU may be running on any
On Mon, Dec 12, 2011 at 10:49 AM, Avi Kivity a...@redhat.com wrote:
On 12/12/2011 05:25 PM, Peter Maydell wrote:
On 12 December 2011 15:15, Avi Kivity a...@redhat.com wrote:
We need to differentiate in how Linux-as-a-guest acts and how the cpu is
supposed to work. A guest operating system
On 12/12/2011 06:31 PM, Peter Maydell wrote:
On 11 December 2011 23:01, Jan Kiszka jan.kis...@web.de wrote:
Enabling in-kernel irqchips usually means switching worlds. So the
semantics of these particular IRQ inject interface details may change
without breaking anything.
However, things
On 2011-12-12 18:37, Avi Kivity wrote:
On 12/12/2011 06:51 PM, Jan Kiszka wrote:
Any thoughts on the qemu-kvm merge plan? Sounds painful.
Pain will be where the existing qemu-kvm extensions collide with these
refactored upstream devices (backend/frontend split specifically).
That's where we
On 12/12/2011 06:20 PM, Christoffer Dall wrote:
+/**
+ * kvm_handle_wfi - handle a wait-for-interrupts instruction executed by
a guest
+ * @vcpu:the vcpu pointer
+ * @run: the kvm_run structure pointer
+ *
+ * Simply sets the wait_for_interrupts flag on the vcpu structure,
On 12/12/11 17:39, Christoffer Dall wrote:
On Mon, Dec 12, 2011 at 9:32 AM, Avi Kivity a...@redhat.com wrote:
On 12/11/2011 12:25 PM, Christoffer Dall wrote:
From: Marc Zyngier marc.zyng...@arm.com
A guest may need to know which CPU it has booted on (and Linux does).
Now that we can run KVM
On 12/12/2011 07:37 PM, Christoffer Dall wrote:
This looks overly complicated with two levels of locks. x86 gets by
with no locks, and a much more complicated interrupt architecture.
My recommendation is:
wait_for_interrupts is managed solely by the vcpu thread
KVM_IRQ_LINE does a
On 12/12/2011 07:42 PM, Jan Kiszka wrote:
It's a little late for this, but refactoring qemu-kvm in-tree and then
splitting it into patches would have been easier. Let's try it this way
for the next batch.
I thought about this, but it definitely takes a clean, qemu-kvm free
base as start.
On 12/12/2011 08:14 PM, Sasha Levin wrote:
On Mon, 2011-12-12 at 17:59 +0200, Pekka Enberg wrote:
On Mon, Dec 12, 2011 at 4:47 PM, Sasha Levin levinsasha...@gmail.com
wrote:
+ /* mmap the actual kernel */
+ kvm-bz_fd = dup(fd_kernel);
+ kvm-bz_len = st.st_size;
On 12/12/2011 04:47 PM, Sasha Levin wrote:
This patch mmaps guest kernel into it's own memory slot instead of reading
it into the memory.
- } else {
- /* First RAM range from zero to the PCI gap: */
+ /* Mapped kernel */
+ phys_start =
On 12/12/2011 04:47 PM, Sasha Levin wrote:
This patch mmaps guest kernel into it's own memory slot instead of reading
it into the memory.
The advantages are:
- Smaller memory footprint (same effect as KSM if running multiple guests)
- Faster loading of larger kernels.
How many COW faults
On 12/09/2011 05:15 PM, Alexander Graf wrote:
On 09.12.2011, at 20:15, Scott Wood wrote:
On 12/09/2011 01:10 PM, Alexander Graf wrote:
On 09.12.2011, at 19:19, Scott Wood scottw...@freescale.com wrote:
On 12/09/2011 09:26 AM, Alexander Graf wrote:
Our vcpu kick implementation differs a
This is required for THIS_MODULE. We recently stopped acquiring it via
some other header.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/e500.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
When commit f43fdc15fa (KVM: PPC: booke: Improve timer register
emulation) factored out some code in arch/powerpc/kvm/powerpc.c
into a new helper function, kvm_vcpu_kick(), an error crept in
which causes Book3s HV guest vcpus to stall. This fixes it.
On POWER7 machines, guest vcpus are grouped
This moves the get/set_one_reg implementation down from powerpc.c into
booke.c, book3s_pr.c and book3s_hv.c. This avoids #ifdefs in C code,
but more importantly, it fixes a bug on Book3s HV where we were
accessing beyond the end of the kvm_vcpu struct (via the to_book3s()
macro) and corrupting
This allocates an array for each memory slot that is added to store
the physical addresses of the pages in the slot. This array is
vmalloc'd and accessed in kvmppc_h_enter using real_vmalloc_addr().
This allows us to remove the ram_pginfo field from the kvm_arch
struct, and removes the 64GB guest
At present, our implementation of H_ENTER only makes one try at locking
each slot that it looks at, and doesn't even retry the ldarx/stdcx.
atomic update sequence that it uses to attempt to lock the slot. Thus
it can return the H_PTEG_FULL error unnecessarily, particularly when
the H_EXACT flag
This removes the code from kvmppc_core_prepare_memory_region() that
looked up the VMA for the region being added and called hva_to_page
to get the pfns for the memory. We have no guarantee that there will
be anything mapped there at the time of the KVM_SET_USER_MEMORY_REGION
ioctl call; userspace
This provides for the case where userspace maps an I/O device into the
address range of a memory slot using a VM_PFNMAP mapping. In that
case, we work out the pfn from vma-vm_pgoff, and record the cache
enable bits from vma-vm_page_prot in two low-order bits in the
slot_phys array entries. Then,
This adds two new functions, kvmppc_pin_guest_page() and
kvmppc_unpin_guest_page(), and uses them to pin the guest pages where
the guest has registered areas of memory for the hypervisor to update,
(i.e. the per-cpu virtual processor areas, SLB shadow buffers and
dispatch trace logs) and then
This adds an array that parallels the guest hashed page table (HPT),
that is, it has one entry per HPTE, used to store the guest's view
of the second doubleword of the corresponding HPTE. The first
doubleword in the HPTE is the same as the guest's idea of it, so we
don't need to store a copy, but
This expands the reverse mapping array to contain two links for each
HPTE which are used to link together HPTEs that correspond to the
same guest logical page. Each circular list of HPTEs is pointed to
by the rmap array entry for the guest logical page, pointed to by
the relevant memslot. Links
This series of patches updates the Book3S-HV KVM code that manages the
guest hashed page table (HPT) to enable several things:
* MMIO emulation and MMIO pass-through
* Use of small pages (4kB or 64kB, depending on config) to back the
guest memory
* Pageable guest memory - i.e. backing pages
This adds the infrastructure to enable us to page out pages underneath
a Book3S HV guest, on processors that support virtualized partition
memory, that is, POWER7. Instead of pinning all the guest's pages,
we now look in the host userspace Linux page tables to find the
mapping for a given guest
The last remaining patches from the preparation series, with changes:
- Map from hugetlbfs does plain statfs (without odd error checking),
checks result of ftruncate()
- Remove typo whereby kvm_cpu__emulate_mmio() calls self.
Cheers,
Matt
Matt Evans (2):
kvm tools: Add ability to map
Add a --hugetlbfs commandline option to give a path to hugetlbfs-map guest
memory (down in kvm__arch_init()). For x86, guest memory is a normal
ANON mmap() if this option is not provided, otherwise a hugetlbfs mmap.
This maps directly from a hugetlbfs temp file rather than using something
like
Different architectures will deal with MMIO exits differently. For example,
KVM_EXIT_IO is x86-specific, and I/O cycles are often synthesised by steering
into windows in PCI bridges on other architectures.
This patch calls arch-specific kvm_cpu__emulate_io() and kvm_cpu__emulate_mmio()
from the
Hi Pekka,
On 09/12/11 17:53, Matt Evans wrote:
kvmtool's types.h includes asm/types.h, which by default on PPC64 brings in
int-l64.h; define __SANE_USERSPACE_TYPES__ to get LL64 types.
This patch also adds CFLAGS to the final link, so that any -m64 is obeyed
when linking, too.
Just noticed
These two patches build on the previous split out arch-specific work. The
first adds a PPC64 build, basic CPU support, guest RAM mapping (using
hugepages),
flat kernel loading and all required arch-specific definitions structures.
With patches to date, this should build PPC but not necessarily
This patch adds a new arch directory, powerpc, basic file structure, register
setup and where necessary stubs out arch-specific functions (e.g. interrupts,
runloop exits) that later patches will provide. The target is an
SPAPR-compliant PPC64 machine (i.e. pSeries); there is no support for PPC32
Some KVM implementations (e.g. PPC) don't yet support ioeventfds, so don't
bomb out/die. virtio-pci is able to function if it instead uses normal IO
port notification.
Signed-off-by: Matt Evans m...@ozlabs.org
---
tools/kvm/Makefile|2 +-
tools/kvm/include/kvm/ioeventfd.h |
This series adds support for a PPC64 platform, SPAPR, on top of the previous
more general PPC64 CPU support. This platform is paravirtualised, with most
of the MMU hypercalls being dealt with in the kernel. Userland needs to
describe the environment to the machine with a device tree, cope with
The generated DT is the bare minimum structure required for SPAPR (on which
subsequent patches for VIO, XICS, PCI etc. will build); root node, cpus, memory.
Some aspects are currently hardwired for simplicity, for example advertised
page sizes, HPT size, SLB size, VMX/DFP, etc. Future support of
This patch adds the basic structure for HV calls, their registration and some of
the simpler calls. A similar layout for RTAS calls is also added, again with
some of the simpler RTAS calls used by the guest. The SPAPR RTAS stub is
generated inline. Also, nodes for RTAS are added to the device
This is the final piece of the puzzle for PPC SPAPR PCI; this
function splits MMIO accesses into the two PHB windows directs
things to MMIO/IO emulation as appropriate.
Signed-off-by: Matt Evans m...@ozlabs.org
---
tools/kvm/Makefile |1 +
101 - 142 of 142 matches
Mail list logo
