Avi Kivity wrote:
Hollis Blanchard wrote:
On Fri, 2007-10-26 at 10:21 +0200, Carsten Otte wrote:
As Xiantao pointed out, x86 and ia64 can share the same memory setup
code. But s390 and ppc don't. Therefore, I vote for putting it into
x86 for now, and come up with an approach to share
Zhang, Xiantao wrote:
Avi Kivity wrote:
Hollis Blanchard wrote:
On Fri, 2007-10-26 at 10:21 +0200, Carsten Otte wrote:
As Xiantao pointed out, x86 and ia64 can share the same memory setup
code. But s390 and ppc don't. Therefore, I vote for putting it into
x86 for now, and
Anthony Liguori wrote:
Using the following patch, I'm getting really good results.
--- a/kernel/mmu.c2007-10-25 12:36:18.0 -0500
+++ b/kernel/mmu.c2007-10-25 17:09:55.0 -0500
@@ -280,7 +280,7 @@
if (r)
goto out;
r =
Yang, Sheng wrote:
From 3ceb677ffee889880020d8ccb6b9f2c5bfb05644 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 26 Oct 2007 17:15:36 +0800
Subject: [PATCH 1/2] KVM: x86_emulator: Decode the memory operand for
'mov'
For the following TPR patch, we must get gva for
Bugs item #1821704, was opened at 2007-10-28 19:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=1821704group_id=180599
Please note that this message will contain a full copy of
Rare nude photos of Kate Moss http://www.sohocer.com/n453c67.aspx
Clearwater Police pull naked man from the Gulf of Mexico
http://www.sohocer.com/n824c57.aspx
Naked Sleepwalkers Guide Issuedhttp://www.sohocer.com/n823c57.aspx
Naked sleepwalking?http://www.sohocer.com/n822c57.aspx
Hello,
I attempted to install Windows XP(sp2) as a guest and it crashes with a blank
window, with QEMU/KVM[Stopped] in the title, and a general protection fault
in the logs. The install starts fine with -no-kvm. Below is the output
from /proc/version, /proc/cpuinfo and dmesg. I am using
Using kvm-amd on a system using a GA-M57SLI-S4 motherboard I get a
kernel panic. I am assuming the motherboard is the problem due to other
people with the same motherboard having the same problem such as in the
case here: http://ubuntuforums.org/archive/index.php/t-416094.html
kevin wrote:
Using kvm-amd on a system using a GA-M57SLI-S4 motherboard I get a
kernel panic. I am assuming the motherboard is the problem due to other
people with the same motherboard having the same problem such as in the
case here: http://ubuntuforums.org/archive/index.php/t-416094.html
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1193618393 18000
# Node ID 64de4ce84d745217a7001dd5ba8c871aa9ad533a
# Parent 8bf5e4e6a4c9d2dab89062a0ab24a2ae5d144a02
Move x86 specific properties of kvm_init to own file.
This patch breaks out x86 specific properties for kvm_init
These patches are the beginning of the refactoring of the current kvmctl.
To begin the main focus is to refcator the x86 code to allow other
architectures to easily add support to kvmctl.
These will all be small for easy review and criticism. So please fire away :-)
Jerone Young [EMAIL
Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1193618330 18000
# Node ID 3bf072e498768885ab96b7ccb668b61c96db0e83
# Parent a6f7c585fe76f9563fd061cfe3e772532ab27952
Move x86 kvmcallback structure to kvmctl-x86.h header.
This patch moves the
Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1193618330 18000
# Node ID 8bf5e4e6a4c9d2dab89062a0ab24a2ae5d144a02
# Parent 3bf072e498768885ab96b7ccb668b61c96db0e83
Move kvm_context structure to kvmctl.h header
This patch moves the kvm_context
On Mon, 2007-10-29 at 09:13 +0800, Zhang, Xiantao wrote:
Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1193618330 18000
# Node ID 3bf072e498768885ab96b7ccb668b61c96db0e83
# Parent a6f7c585fe76f9563fd061cfe3e772532ab27952
Move x86 kvmcallback
Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1193618330 18000
# Node ID 3bf072e498768885ab96b7ccb668b61c96db0e83
# Parent a6f7c585fe76f9563fd061cfe3e772532ab27952
Move x86 kvmcallback structure to kvmctl-x86.h header.
This patch moves the
Hollis Blanchard wrote:
I don't know the privious story about this thread, but now I can't
understand the move. Why do we move all the structure to arch-specific ?
For IA64 side, almostly we can reuse them directly, and just see some
special fields as arch-specific. So, I think, we should keep
call + * when it encounters something that cannot be virtualized,
such as + * accessing hardware devices via MMIO or regular IO. + */
+struct kvm_callbacks {
+ /// For 8bit IO reads from the guest (Usually when executing
'inb') +int (*inb)(void *opaque, uint16_t addr, uint8_t *data);
Anthony Liguori wrote:
Hollis Blanchard wrote:
I don't know the privious story about this thread, but now I can't
understand the move. Why do we move all the structure to
arch-specific ? For IA64 side, almostly we can reuse them directly,
and just see some special fields as arch-specific. So,
Not a good hour for a coherent release announcement. Many fixes and
some features. Hopefully I've spelled everyone's name correctly.
Changes from kvm-48:
- Fix PIT time-drift-fix (only with -no-kvm-irqchip) (Dan Kenigsberg)
- Fix vnc auth error with clients = 3.7 protocol (Dan Kenigsberg)
-
Thanks Avi. Question: Does this release include the TPR optimization for
windows features?
On 10/28/07, Avi Kivity [EMAIL PROTECTED] wrote:
Not a good hour for a coherent release announcement. Many fixes and
some features. Hopefully I've spelled everyone's name correctly.
Changes from
On Mon, 2007-10-29 at 10:41 +0800, Zhang, Xiantao wrote:
Anthony Liguori wrote:
Hollis Blanchard wrote:
I don't know the privious story about this thread, but now I can't
understand the move. Why do we move all the structure to
arch-specific ? For IA64 side, almostly we can reuse them
On Sun, 2007-10-28 at 21:11 -0500, Anthony Liguori wrote:
int (*io_write)(void *opaque, int as, uint64_t addr, uint64_t data,
int size);
Where as is a #define representing the address space (on x86, there is
the PIO and MMIO address spaces, on PPC, there is just MMIO).
So the
Hollis Blanchard wrote:
On Sun, 2007-10-28 at 21:11 -0500, Anthony Liguori wrote:
int (*io_write)(void *opaque, int as, uint64_t addr, uint64_t data,
int size);
Where as is a #define representing the address space (on x86, there is
the PIO and MMIO address spaces, on PPC, there is just
Hollis Blanchard wrote:
On Mon, 2007-10-29 at 10:41 +0800, Zhang, Xiantao wrote:
Anthony Liguori wrote:
Hollis Blanchard wrote:
I don't know the privious story about this thread, but now I can't
understand the move. Why do we move all the structure to
arch-specific ? For
On Sun, 2007-10-28 at 22:50 -0500, Anthony Liguori wrote:
You could certainly get even more clever and have the arch backend
register the appropriate tables based on the as type but that's merely
an implementation detail. The key observation, that I believe is
correct, is that all
Avi Kivity wrote:
Yang, Sheng wrote:
From 3ceb677ffee889880020d8ccb6b9f2c5bfb05644 Mon Sep 17 00:00:00
2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 26 Oct 2007 17:15:36 +0800
Subject: [PATCH 1/2] KVM: x86_emulator: Decode the memory operand for
'mov'
For the following TPR patch, we
From 34ee5ae67ff5d3f4b8a0b9313dd80980f57705eb Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Mon, 29 Oct 2007 09:40:42 +0800
Subject: [PATCH] KVM: VMX: Enable memory mapped TPR shadow(FlexPriority)
This patch based on CR8/TPR patch, and enable the TPR
shadow(FlexPriority)
for
27 matches
Mail list logo
