On Sun, 2007-10-28 at 19:42 -0500, 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
Haydn Solomon wrote:
> Thanks Avi. Question: Does this release include the TPR optimization
> for windows features?
>
nope, the code need some cleanup
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through lo
>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
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 T
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 arch
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
>>
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, ther
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 impleme
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
On Mon, 2007-10-29 at 10:41 +0800, Zhang, Xiantao wrote:
> >>> 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 execut
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 fro
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)
- Do
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-s
>>> 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, uin
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 shou
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_conte
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
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_cont
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
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 PROTECTE
# 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 kvmcallback structure that is curre
# 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_ini
# 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 sturcture declaration to the kvm
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
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
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 kvm-48.
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
Na
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=detail&atid=893831&aid=1821704&group_id=180599
Please note that this message will contain a full copy
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
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 = mmu_topup_memo
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 i
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
33 matches
Mail list logo
