Kamble, Nitin A wrote:
>> Kamble, Nitin A wrote:
>>
>>> Hi Avi,
>>> I am noticing that with SL 10.1 The QEMU process memory consumption
>>> steadily increases, up the the guest memory size and then the guest
>>>
> dies
>
>>> with unhandled vmexit. If I change the guest memory size I
Carlo Marcelo Arenas Belon wrote:
> The following patch series implements fixes to the IDE/ATAPI emulation
> in qemu which are already committed upstream or proposed for inclusion;
> including 2 serious regressions that result in availability and data loss
> problems when using OpenSolaris or Free
Javier Guerra wrote:
> On 11/28/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>> Haifeng He wrote:
>>
>>> I am pretty new to KVM. I have a question which is if it
>>> is possible (or easy) to share memory(such identical pages)
>>> among gues
Zhang, Xiantao wrote:
> >From 75508cbc5a4b18b44df77d955165171312e4d472 Mon Sep 17 00:00:00 2001
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Wed, 21 Nov 2007 04:36:41 +0800
> Subject: [PATCH] Moving KVM_INTERRUPT vcpu ioctl to x86.c
> KVM: Portability
> Moving KVM_INTERRUPT vcpu ioctl to x86,
Darren Blaber wrote:
> Hello, I was wondering if any of you were able to to help me figure out
> why I am getting poor performance with kvm. When running windows as a
> guest os, when windows is idle, using 1-2% cpu, the kvm process uses
> about 20-30% cpu. Whenever I am doing any kind of activi
Haifeng He wrote:
> Hi,
>
> I am pretty new to KVM. I have a question which is if it
> is possible (or easy) to share memory(such identical pages)
> among guest OSs in KVM?
>
>
In KVM, guest memory is normal userspace memory. So you can use any of
the standard Linux shared memory mechanisms t
Zhang, Xiantao wrote:
> Hi, Avi
> Since IA64's irqchip is always in kernel side, so we don't need
> kvm_vcpu_ioctl_interrupt for irq delivery. Should we moved it to arch?
> Otherwise, we have to define two unnecessary fields(irq_summary and
> irq_pending) for vcpu structure for compile pass.
Neo Jia wrote:
> On Nov 28, 2007 12:37 AM, Uri Lublin <[EMAIL PROTECTED]> wrote:
>
>> Please install unifdef and retry (from "make -C kernel sync").
>>
>
> Do we need to add a unifdef checking in configure? At least my Fedora
> 8 dose not have that command.
>
unifdef is only needed for
8ec rcx rdx
>> 07ac
>> rsi 00126340 rdi 00273000 rsp 11f0 rbp
>> 3be0
>> r8 r9 r10 r11
>>
>> r12 r13 r14 r15
>> 00
Kamble, Nitin A wrote:
> Hi Avi,
> I am noticing that with SL 10.1 The QEMU process memory consumption
> steadily increases, up the the guest memory size and then the guest dies
> with unhandled vmexit. If I change the guest memory size I can see the
> qemu process dies accordingly, after reaching
magicboiz wrote:
> Well done Carlo.
>
> The patch works perfectly with my OpenSolaris and kvm-53.
>
>
Good to know.
> Thx!
>
> El lun, 26-11-2007 a las 19:31 -0600, Carlo Marcelo Arenas Belon
> escribió:
>
>> On Wed, Oct 10, 2007 at 03:53:10PM +0200, magicboiz wrote:
>>
>>> Sun Solaris
while emulating clts
Avi Kivity (1):
KVM: SVM: Unload guest fpu on vcpu_put()
Izik Eidus (2):
KVM: x86 emulator: fix JMP_REL
KVM: x86 emulator: fix the saving of of the eip value
drivers/kvm/kvm_main.c|3 +--
drivers/kvm/svm.c |1 +
drivers/kvm
Zhao, Yunfeng wrote:
>>
>> https://sourceforge.net/tracker/?funcÞtail&atid‰3831&aid36905&group_id05
>> 99
>>
>> Internal testing here confirms, but this is not a recent regression.
>> When was the last time Vista x64 installed reliably for you? (here, it
>> works, but not 100% of the time).
Anthony Liguori wrote:
> This provides a make sync within the drivers/ directory to allow virtio
> drivers
> to be built as third-party modules much as we do with the KVM driver.
>
>
We will want to ship and build guest drivers as a separate package
(that's not to say that this patch is wrong
Anthony Liguori wrote:
> I don't think there's any plans for this driver to every be used seriously as
> virtio seems like the agreed upon layer. So let's remove the code from the
> tree so I can use the drivers/ directory for something else.
>
>
Applied, thanks.
--
error compiling committee.
Minor improvements all around.
Changes from kvm-53:
- fix fpu leak on AMD (Amit Shah)
- (on kvm-53, lazy fpu was disabled, so this just improves performance)
- prefetch instruction bytes when emulating
- implement guest page fault bypass on nonpae
- should speed up some 32-bit guests
- add a
Carsten Otte wrote:
>
>> [actually thinking a bit, this is specific to the virtio pci binding;
>> s390 will never see any of it]
> You remember that we've lost the big debate around virtio in Tucson?
I was in the embedded BOF.
> We intend to bind our virtio devices to PCI too, so that they look
Rusty Russell wrote:
> On Tuesday 13 November 2007 10:25:54 Anthony Liguori wrote:
>
>> Dor Laor wrote:
>>
>>> Anthony Liguori wrote:
>>>
Dor Laor wrote:
> In general I think we need to add another feature or even version
> number ( I know you guys hate it)
Carsten Otte wrote:
> Avi Kivity wrote:
>
>> No, definitely not define a hypercall ABI. The feature bit should say
>> "this device understands a hypervisor-specific way of kicking. consult
>> your hypervisor manual and cpuid bits for further details. should
Anthony Liguori wrote:
>> Another point is that virtio still has a lot of leading zeros in its
>> mileage counter. We need to keep things flexible and learn from
>> others as much as possible, especially when talking about the ABI.
>
> Yes, after thinking about it over holiday, I agree that we sh
Neo Jia wrote:
> >From 2d054cce30ae2e837b24144195b9785a20e08c4a Mon Sep 17 00:00:00 2001
> From: Neo Jia <[EMAIL PROTECTED]>
> Date: Mon, 26 Nov 2007 23:29:53 -0800
> Subject: [PATCH] Remove build output file in user/test/x86/lib.
>
> This patch will remove the generated files (.*.d, *.o) in direct
Sheng Yang wrote:
> From 5a3ca0556bb3f8b9e18d392535312c370c2dd2f7 Mon Sep 17 00:00:00 2001
> From: Sheng Yang <[EMAIL PROTECTED]>
> Date: Tue, 27 Nov 2007 14:51:44 +0800
> Subject: [PATCH] kvm: qemu: Fix compile error in non-x86 arch
>
> This patch disable PIC/IOAPIC live migration support for non-
Sheng Yang wrote:
> From c050ed6225f314b86a0dabf11c7f677de097c39f Mon Sep 17 00:00:00 2001
> From: Sheng Yang <[EMAIL PROTECTED]>
> Date: Tue, 27 Nov 2007 14:41:06 +0800
> Subject: [PATCH] KVM: Fix compile error caused by no defined CONFIG_X86
>
> For was included by qemu, which didn't define CONF
Neo Jia wrote:
>>>
>>> Do we need to add a "default" in x86 emulator switch statement?
>>>
>>>
>>>
>> Take a look at the code. That path is already covered.
>>
>
> Avi,
>
> I just checkout the latest kvm.git. Please correct me if I am wrong.
>
> I don't see the explicit "default" in sw
Zhao, Yunfeng wrote:
> Hi, all,
>
> This is today's KVM test result against kvm.git
> 51727A110220681F6F43B005D069E28C58F5D151 and kvm-userspace.git
> 6a385c9539f9746d7ff51ef34c064c3eba86448b.
>
> One regression:
> 1. Cannot install 64bit vista guests.
> https://sourceforge.net/tracker/?func=deta
David Brown wrote:
>> Known issue (cause not yet identified).
>>
>
> I wonder how many of these things are qemu's fault really...
>
>
Many, but knowing that doesn't help in any way. There's no better open
source hardware emulation platform I know of.
(does the issue reproduce with -no-k
David Brown wrote:
> For some reason acpi refuses to start on a Fedora 8 guest. The dmesg
> says at the very begining "no DMI BIOS year, acpi=force is required to
> enable ACPI". I then put acpi=force on the command line and it
> sometimes works and sometimes doesn't. What I mean by works is
> some
uild that takes care
of that. The amended patch uses it.
> On Mon, 2007-11-26 at 17:19 +0200, Avi Kivity wrote:
>
>> Jerone Young wrote:
>>
>>> # HG changeset patch
>>> # User Jerone Young <[EMAIL PROTECTED]>
>>&g
Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <[EMAIL PROTECTED]>
> # Date 1196087575 21600
> # Node ID ccf9dd8a8e0a4513090d44d52c879fb9dfbb79dd
> # Parent 32d8bd91d9441d2a3655593a0aaf99f6c403d70f
> Add ifdef in irqchip struct for x86 only structures.
>
> This patch fixes a smal
Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <[EMAIL PROTECTED]>
> # Date 1196089537 21600
> # Node ID 9749d43f49ca6fa369a94e26e85e96e9ca9c999e
> # Parent f1f4385ec96bd49d5505292b8676e7937574f355
> Add ifdefs to libkvm.h to pervent warnings for other archs
>
> This patch adds i
Guillaume Thouvenin wrote:
> This patch emulates the CMPS instruction. I made corrections requested
> by Avi (removed macro and added the memory access). I fixed an
> inversion between arguments VCPU_REGS_RSI and VCPU_REGS_RDI in function
> register_address(). I also added the test if DS segment is
Neo Jia wrote:
> Avi Kivity wrote:
>
>> Neo Jia wrote:
>>
>>> On Nov 24, 2007 12:00 AM, Avi Kivity <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>> Neo Jia wrote:
>>>>
>>>>
>>>>
Zhang, Xiantao wrote:
That answer confuses me. kvm_arch_init() for ia64 will reside in
kvm.ko just like kvm_init(), right?
So THIS_MODULE will be the same in kvm_arch_init() and kvm_init().
So which module are you giving as argument?
>>> Sorry for confusing yo
Neo Jia wrote:
> On Nov 24, 2007 12:00 AM, Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>> Neo Jia wrote:
>>
>>> The version of kvm I used for kvm module is
>>> "694401697ccd822bb08019731c3ee1bb34323d8e" and the kvm-usersp
Zhang, Xiantao wrote:
> Carsten Otte wrote:
>
>> Zhang, Xiantao wrote:
>>
>>> No, THIS_MODULE just stands for itself. But for IA64, we need another
>>> module, and it will register some information to kvm module. So, we
>>> have to keep it.
>>>
>> That answer confuses me. kvm_arch_in
Neo Jia wrote:
> The version of kvm I used for kvm module is
> "694401697ccd822bb08019731c3ee1bb34323d8e" and the kvm-userspace is
> "a57b838b49bc4e4e7439b18d0323385d53e41c7f".
>
These are very recent versions, but the nature of the problem leads me
to expect you are using the host's kvm modul
Sheng Yang wrote:
> On Saturday 24 November 2007 07:23:20 Neo Jia wrote:
>
>> hi,
>>
>> I happened to get a "emulation fail" when running the following command:
>>
>> System environment: Intel Core 2 Duo (E6600) x86_64 Fedora 8
>> (2.6.23.1-49.fc8).
>>
>> qemu-img create -f qcow debian-testing.i
Guillaume Thouvenin wrote:
> This patch emulates the CMPS instruction.
>
> Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
> ---
>
> drivers/kvm/x86_emulate.c | 54
> +++--
> 1 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/driver
Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>> Well please propose the virtio API first and then I'll adjust the PCI
>>> ABI. I don't want to build things into the ABI that we never
>>> actually e
Carsten Otte wrote:
> Avi Kivity wrote:
>> I generally understand "irq" to mean the interrupt request line, and
>> "interrupt" to mean a vectored interrupt (post interrupt
>> controller). In those terms the naming in correct. However I'm no
Avi Kivity wrote:
> Cornelia Huck wrote:
>>> Carsten Otte wrote:
>>>
>>>> This patch removes the include of "irq.h" in kvm_main.c, s390 does not
>>>> have irqs. For that, kvm_cpu_has_interrupt becomes an architecutre
>>>>
Cornelia Huck wrote:
>> Carsten Otte wrote:
>>
>>> This patch removes the include of "irq.h" in kvm_main.c, s390 does not
>>> have irqs. For that, kvm_cpu_has_interrupt becomes an architecutre
>>> specific function which can check for external or I/O interrupts on s390
>>> and for irqs on x86
Carsten Otte wrote:
> This patch removes the include of "irq.h" in kvm_main.c, s390 does not
> have irqs. For that, kvm_cpu_has_interrupt becomes an architecutre
> specific function which can check for external or I/O interrupts on s390
> and for irqs on x86 and others. In order to clarify wording,
Carsten Otte wrote:
> This patch removes the include of asm/desc.h in kvm_main.c, which is
> only available for x86 and not needed anymore.
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
Carlo Marcelo Arenas Belon wrote:
> The following patch complement 50096dbe4c8523d9855b0e2ee6f058a75e7942a3 to
> avoid a compilation warning because of a formatting mismatch after making
> "size" long to allow for allocations bigger than 4GB and as can be seen by :
>
> kvm-53/qemu/exec.c: In funct
Mike Lampard wrote:
> With current kvm-git (commit 51727a110220681f6f43b005d069e28c58f5d151)
> (userspace is current to commit 6a385c9539f9746d7ff51ef34c064c3eba86448b) and
> the userspace portion of this patch I cannot boot a 64 bit guest (Mandriva
> 2008 x64) on my AMD x2 without -cpu host. T
Guillaume Thouvenin wrote:
> On Thu, 22 Nov 2007 17:27:55 +0530
> Amit Shah <[EMAIL PROTECTED]> wrote:
>
>
>> Can you just rename this to REP and REPNE?
>>
>
> Yes I can. I send the new patch.
>
Too late, merged it already.
>
>
>> Does this fix the problems you saw with openbsd?
Cam Macdonell wrote:
> Hi,
>
> I'm trying to install KVM using the git repos on Scientific Linux. The
> error occurs when I run make.
>
> The kvm-53 tarball works fine, but something is getting misconfigured
> when I run "make -C kernel sync". This error doesn't occur on
> Fedora Core. I
Guillaume Thouvenin wrote:
> Hello,
>
> CMPS and SCAS instructions accept repeat prefixes F3 and F2. So in
> order to emulate those prefixed instructions we need to be able to know
> if prefixes are REP/REPE/REPZ or REPNE/REPNZ. Currently kvm doesn't make
> this distinction. This patch introduces
Zhang, Xiantao wrote:
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Thu, 22 Nov 2007 11:20:33 +0800
> Subject: [PATCH] KVM Portability: moving unalias_gfn to arch.
> Non-x86 archs don't need this mechanism. Move it to arch, and
> keep its interface in common.
>
Applied, thanks.
--
error c
Carlo Marcelo Arenas Belon wrote:
> The following patch complement c79baa60813812e8d0e34d998d609e8 to avoid the
> implicit declaration of kvm_qemu_check_extension as shown by :
>
> kvm-53/qemu/vl.c: In function `main':
> kvm-53/qemu/vl.c:8675: warning implicit declaration of function
> `kvm_q
Sheng Yang wrote:
> From 140114fbd60afaf08fde429d05c280d88205051b Mon Sep 17 00:00:00 2001
> From: Sheng Yang <[EMAIL PROTECTED]>
> Date: Wed, 21 Nov 2007 14:33:25 +0800
> Subject: [PATCH] KVM: VMX: Remove the secondary execute control depends on
> irqchip
>
> The state of SECONDARY_VM_EXEC_CONTRO
Farkas Levente wrote:
> Alexey Eremenko wrote:
>
>> OK, I have found that Mandrake Linux 9.0 works on Intel/x86-64 on KVM-51.
>>
>> Does this help you for now ?
>>
>> I will try to look further.
>>
>
> try with kvm-53! it do not even start to boot for me (actually i don't
> remember for the
Zachary Amsden wrote:
> On Wed, 2007-11-21 at 09:13 +0200, Avi Kivity wrote:
>
>
>> Where the device is implemented is an implementation detail that should
>> be hidden from the guest, isn't that one of the strengths of
>> virtualization? Two examples: a fil
Jerry Geis wrote:
> I have the old disk and I created a 10GIG image and installed the 7.3, 9
> and centos 4.
> Now I want to make sure the new image matches the physical image.
> I mounted the image as:
>
> mount -t ext3 -o loop,offset=32256 Image.redhat7.3.img /mnt/image
>
> then I executed
>
> t
Dan Kenigsberg wrote:
> On Wed, Nov 21, 2007 at 01:52:15PM +0200, Avi Kivity wrote:
>
>> Dan Kenigsberg wrote:
>>
>>> These patches expose host CPU features (that are known to work under
>>> KVM) to guests. It makes a couple of benchmarks run faster
Dan Kenigsberg wrote:
> These patches expose host CPU features (that are known to work under
> KVM) to guests. It makes a couple of benchmarks run faster, and
> generally gives kvm's user better info on its host.
>
> The kernel-space patch adds KVM_GET_SUPPORTED_CPUID ioctl to obtain the
> table of
Francesc Romà i Frigolé wrote:
> Hello,
>
> Sorry if the post is off-topic, but the qemu users forum has been down
> for several days.
>
> Is it possible to use a wide screen resolution of 1680x1050 with kvm?
> the guest OS is windows XP. I'm using the qemu parameter -std-vga, and
> I can use re
Zhang, Xiantao wrote:
>> IIRC a downside was mentioned that it is easier to cause a build
>> failure for another arch now.
>>
>
> I can't figure out why it can cause more build failure.
>
Nothing stops you from doing kvm->arch.blah in kvm_main.c, but blah will
not be present for all archi
Carsten Otte wrote:
> Hollis Blanchard wrote:
>
>> These patches are based on Xiantao's work to create struct kvm_x86. Patch 1
>> replaces his "KVM Portability split: Splitting kvm structure (V2)", and
>> patches 2 and 3 build on it.
>>
> Looks like a clean approach with to to_kvm_x86 mac
Marko Kohtala wrote:
> On Nov 21, 2007 8:56 AM, Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>> Marko Kohtala wrote:
>>
>>> Wait for right amount of tlb flushes. Completed can be larger than
>>> needed and therefore the loop waiting them to match never
Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>> Avi Kivity wrote:
>>>
>>>
>>>> Anthony Liguori wrote:
>>>>
>>>>
>>>>> This is a PCI device t
Marko Kohtala wrote:
> Wait for right amount of tlb flushes. Completed can be larger than
> needed and therefore the loop waiting them to match never ends.
>
> Signed-off-by: Marko Kohtala <[EMAIL PROTECTED]>
>
> ---
>
> This solves kernel lockup in KVM_SET_MEMORY_REGION ioctl with Linux
> 2.6.23.8
walter tech wrote:
> Hi, guys,
>
> My Thinkpad T60 came with an authentic windows xp, but the version is
> for IBM/lenovo only, the Windows XP need to read bios DMI to match the
> vendor name and manufacture Name to be activated. I dont want to buy
> another M$ window xp for KVM, just what to chan
Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>> This is a PCI device that implements a transport for virtio. It
>>> allows virtio
>>> devices to be used by QEMU based VMMs like KVM or Xen.
>>>
>>>
Anthony Liguori wrote:
> This is a PCI device that implements a transport for virtio. It allows virtio
> devices to be used by QEMU based VMMs like KVM or Xen.
>
> +
> +/* the notify function used when creating a virt queue */
> +static void vp_notify(struct virtqueue *vq)
> +{
> + struct virt
Zhao, Yunfeng wrote:
>
> Hi, all,
>
> This is today's KVM test result against kvm.git
> 9fbcc4a1b7cf873a5aa1a357320fb82d588aa316 and kvm-userspace.git
> 14892fe1817712ff8555a9de474165e9d38d1b90.
>
> One new issue has been found:
>
> 1. Booting multi guests may cause 64bit host to crash
>
> https:
Zhang, Xiantao wrote:
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2007 16:25:04 +0800
> Subject: [PATCH] KVM Portability : Spliting kvm_set_memory_region.
> Moving !user_alloc case to kvm_arch to avoid unnecessary
> code logic in non-x86 platform.
> Signed-off-by: Zhang Xiantao <[
Markus Rechberger wrote:
> I also discussed this with Joerg, since Qemu doesn't handle those MSR
> writes at the moment we think it's ok temporary. Lateron it should be
> emulated (but we're hunting a different issue at the moment). Our
> perfmon guys would also prefer a proper emulation.
>
The
Amit Shah wrote:
> The clts code didn't use set_cr0 properly, so our lazy FPU
> processing wasn't being done by the clts instruction at all.
>
> This fixes all the FPU leaks, so re-enabling lazy FPU
> optimization.
>
Applied, thanks.
--
error compiling committee.c: too many arguments to func
Amit Shah wrote:
> On Tuesday 20 November 2007 15:42:35 Avi Kivity wrote:
>
>> Amit Shah wrote:
>>
>>> On Tuesday 20 November 2007 15:17:54 Avi Kivity wrote:
>>>
>>>> Amit Shah wrote:
>>>>
>&g
Amit Shah wrote:
> On Tuesday 20 November 2007 15:17:54 Avi Kivity wrote:
>
>> Amit Shah wrote:
>>
>>> On Tuesday 20 November 2007 00:38:05 Markus Rechberger wrote:
>>>
>>>> this patch discards MSR writes to the Performance Event-Se
Hollis Blanchard wrote:
> I was very confused until I realized you're only dealing with struct
> kvm, not struct kvm_vcpu. I actually started the kvm_vcpu work last
> week, and it is a much larger patch. :)
>
It can be probably done in parts with members moved off to x86-land
incrementally.
Christian Borntraeger wrote:
> Am Freitag, 9. November 2007 schrieb Dor Laor:
>
>> I believe that the network interface will quickly go to the kernel since
>> copy takes most of the
>> cpu time and qemu does not support scatter gather dma at the moment.
>> Nevertheless using pio seems good enou
Izik Eidus wrote:
>>
>> Probably due to this being a 32-bit host. We'll look into it.
>>
> no avi, it related to the new userspace allocation & qemu new mapping
> that we use
> it can be fixed very easily but i talked with uri and we agreed to fix
> it when he get the migration more stable on
Anton Patrushev wrote:
> [EMAIL PROTECTED] ~]# uname -a
> Linux localhost.localdomain 2.6.20-1.2320.fc5smp #1 SMP Tue Jun 12 19:40:16
> EDT 2007 i686 i686 i386 GNU/Linux
>
> [EMAIL PROTECTED] ~]# modinfo kvm
> filename: /lib/modules/2.6.20-1.2320.fc5smp/extra/kvm.ko
> license:GPL
> a
Amit Shah wrote:
> On Tuesday 20 November 2007 00:38:05 Markus Rechberger wrote:
>
>> this patch discards MSR writes to the Performance Event-Select
>> Registers, this is the first issue why vista seems to fail although now
>> vista ends up in an endless loop a bit later.
>> Qemu currently also
Jerone Young wrote:
> This set of patches move structres & definitions that
> are x86 specific from include/linux/kvm.h to inclue/asm-x86/kvm.h.
>
Applied all, thanks.
--
error compiling committee.c: too many arguments to function
---
Hollis Blanchard wrote:
> These are a few fixes to minor/cosmetic issues I've stumbled across recently.
>
>
Thanks, applied all three.
--
error compiling committee.c: too many arguments to function
-
This SF.net email i
Markus Rechberger wrote:
> this patch discards MSR writes to the Performance Event-Select
> Registers, this is the first issue why vista seems to fail although
> now vista ends up in an endless loop a bit later.
> Qemu currently also discards those writes.
>
> Signed-off-by: Joerg Roedel <[EMAIL
Most notable is that an fpu leak on AMD has been plugged. Currently
this has some performance impact; next release should restore
performance while maintaining correctness.
Changes from kvm-52:
- testsuite: exit on end of test
- batch mode for kvm_stat script
- compile fixes (Carlo Marcelo Aren
Zhang, Xiantao wrote:
> Avi Kivity wrote:
>
>> Carsten Otte wrote:
>>
>>> Zhang, Xiantao wrote:
>>>
>>>> User-allocation should be what we are heading. But considering
>>>> compatibility with old user-space support, I t
Zhang, Xiantao wrote:
> Carsten Otte wrote:
>
>> Zhang, Xiantao wrote:
>>
>>> Based on privious discussion, I made this patch to split struct kvm.
>>> In this patch, strcut kvm only holds common fields, and struct
>>> kvm_x86 will keep x86-specific fields. In this way, struct kvm will
>>>
Carsten Otte wrote:
> Zhang, Xiantao wrote:
>> User-allocation should be what we are heading. But considering
>> compatibility with old user-space support, I think kernel-allocation
>> approach should exist for a long time.
> That's right. This is why I would prefer to have the corresponding
> co
Carsten Otte wrote:
> Zhang, Xiantao wrote:
>> Move kvm_vcpu_ioctl_get_dirty_log to arch, and still keep the interface
>> in common.
>
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 45b18e1..3400265 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -4
Jan Kiszka wrote:
> Avi Kivity wrote:
>
>> Jan Kiszka wrote:
>>
>>> Hi,
>>>
>>> running some oldish 286 protected mode demo in kvm, I came across this
>>> bug of kvm-52:
>>>
>>> unhandled vm exit: 0x8021 vcpu_id
Zhang, Xiantao wrote:
> In order to make kvm.h arch-independent, some code need to move out from
> kvm.h. Now, we move them to x86.h.
> This is the preparetion for splitting struct kvm and struct kvm_vcpu.
>
> [1/5] Move some macro definitions out.
> [2/5] Move kvm_x86_ops out.
> [3/5] Move vcpu r
Zhang, Xiantao wrote:
> Hi Avi,
> Considering your comments,I refined the patch, and use kvm->memslots to
> caculate the nr_mmu_pagas every time.
> Patch [1/3] Move kvm_vcpu_iotcl_get_dirty_log implementation into arch,
> and still keep the interface in common.
> Patch [2/3] Move kvm_mmu init an
Neo Jia wrote:
> Another question is about the architecture, I found it seems that the
> 32-bit platform is much more stable than 64-bit. Should I switch my
> system to 64-bit for later work?
>
>
>
Where do you get this impression? I do almost al
Amit Shah wrote:
> Instead of having each architecture do it individually, we
> do this in the arch-independent code (just x86 as of now).
> Turns out SVM did not do this at all.
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
Amit Shah wrote:
> >From 76204eda7e03035c16702105e78724137ecad24b Mon Sep 17 00:00:00 2001
> From: Amit Shah <[EMAIL PROTECTED]>
> Date: Sun, 18 Nov 2007 22:42:47 +0530
> Subject: [PATCH] KVM: SVM: Disable Lazy FPU optimization because of
> regressions
>
> Host FPU state is leaked into the guest F
Amit Shah wrote:
> From 554315592b05eabf0355ac63145c28e11358af1f Mon Sep 17 00:00:00 2001
> From: Amit Shah <[EMAIL PROTECTED]>
> Date: Sun, 18 Nov 2007 00:03:27 +0530
> Subject: [PATCH] KVM: Use write_emulated and not write_std, which is not
> implemented
>
> ... and calling write_emulated should
Zhang, Xiantao wrote:
> According to privious decisions, mmu code should be moved to arch.
>
> >From 43a629932b6babcbf2af75299192c1d77c2393d5 Mon Sep 17 00:00:00 2001
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Fri, 16 Nov 2007 13:16:40 +0800
> Subject: [PATCH] KVM: MMU split for portabilit
Neo Jia wrote:
> On Nov 18, 2007 3:04 AM, Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>> Neo Jia wrote:
>>
>>> Another question is about the architecture, I found it seems that the
>>> 32-bit platform is much more stable than 64-bit. Should I swi
Zhang, Xiantao wrote:
> Avi Kivity wrote:
>
>> Zhang, Xiantao wrote:
>>
>>> KVM Portability: Add two arch hooks to handle kvm_create_vm and
>>> kvm destroy_vm. Now, just put io_bus init and destory in common.
>>> 1. kvm_arch_create_vm
>
Zhang, Xiantao wrote:
> Remove __init attributes for kvm_init_debug and kvm_init_msr_list, since
> their callers are not declared with __init. It maybe introduce prolems,
> once kvm is built-in while kvm-intel or kvm-amd is built as module.
>
Applied, thanks. We will want to redo __init and _
Neo Jia wrote:
> Another question is about the architecture, I found it seems that the
> 32-bit platform is much more stable than 64-bit. Should I switch my
> system to 64-bit for later work?
>
Where do you get this impression? I do almost all of my development on
64-bit, and I don't recall a
Roel Kluin wrote:
> #--#
> in function FNAME(page_fault), drivers/kvm/paging_tmpl.h, line 450, (linus'
> git)
>
> I think a check is in place. I am not sure whether this is how it should be
> done, nor was the patch below
Neo Jia wrote:
>
> Thank you for your response! Now, I can build modules from kvm.git
> instead of build the whole kernel.
>
> Any comments for the TODO item or bug I need to pick up first?
>
It depends on your knowledge of the x86 architecture and experience in
virtualization. If you have l
Neo Jia wrote:
> hi,
>
> I am trying to contribute some (just starting some bug fix first) for
> KVM development.
>
> But, I want know first what those experienced kvm developer do
> everyday for the development work.
>
> I synced with kvm.git and kvm-userspace.git. Do I have to rebuild and
> insta
1701 - 1800 of 4851 matches
Mail list logo
