This one can force qemu to execute reset ops in BSP only.
As addition to previous user level patch.
But if BSP is halted and executing some code without backing
to user level, then we have trouble. But I won't worry about this
right now, since it is also impact device model performance
if KVM does
On Wed, Oct 10, 2007 at 07:38:55PM +0200, Oliver Kowalke wrote:
> Will this patch be included into the new kvm version (46)?
>
No. Hopefully it will be included in a near future version of kvm.
>
> hmm - Iget an error:
> patch -p1 < ./qemu.patch
>
> patching file qemu/hw/pc.c
> patch: mal
Anthony de Almeida Lopes wrote:
> I was curious if anyone thinks that it may be possible to get a
> KVM-patched QEMU to use a real video card? For example, let's say I had
> a second video card. Is QEMU/kvm a codebase which would support hacking
> in the ability to utilize this second video card
Laurent Vivier wrote:
>
> Anthony de Almeida Lopes wrote:
> > I was curious if anyone thinks that it may be possible to get a
> > KVM-patched QEMU to use a real video card? For example, let's say I had
> > a second video card. Is QEMU/kvm a codebase which would support hacking
> > in the ability to
Cam Macdonell wrote:
Izik Eidus wrote:
> Cam Macdonell wrote:
>> Hi,
>>
>>
> sorry, but patch for that feature was already wrote by someone.
>
> but you are more than welcome to try/ask about something else.
Ah, I should've searched the list. Is there another project of similar
scope that w
Dor Laor wrote:
> Laurent Vivier wrote:
>>
>> Anthony de Almeida Lopes wrote:
>> > I was curious if anyone thinks that it may be possible to get a
>> > KVM-patched QEMU to use a real video card? For example, let's say I had
>> > a second video card. Is QEMU/kvm a codebase which would support hackin
Jim Paris wrote:
> If I stop KVM in the monitor with "stop", wait a minute, and do
> "cont", a Linux guest gives me a "BUG: soft lockup detected on CPU#0".
> Is that expected behavior?
We have the same behavior on s390 when running in a virtual
environment. The issue is, that the guest physical
Hi all,
Per our privious discussions about source layout, I just worked out
these patches to support new CPU archs for KVM.
Firslty, we just move all files to its final position in source
structure as we discussed before. In the drivers/kvm directory
I add an x86 directory to hold x86 specific c
>From cdbc4c54cf65e46e5545fe44c9a31ae457385ee0 Mon Sep 17 00:00:00 2001
From: Zhang xiantao <[EMAIL PROTECTED]>
Date: Thu, 11 Oct 2007 16:42:46 +0800
In order to adapt different architectures, we have to change it to an
neutral name. kvm_ops maybe not the best name, but shouldn't introduce
differe
To give a statement from other architectures I wanted to say that this patch is
fine for the power port.
>From my view it is the small and easy-to-review flavor of the big patch series
>I once sent to the list.
And because Carsten and I sit in the same office these patches are usually
reviewed/d
>From 70477d03b238ca76c76d51a1b03f6cee8bb0965c Mon Sep 17 00:00:00 2001
From: Zhang xiantao <[EMAIL PROTECTED]>
Date: Thu, 11 Oct 2007 16:40:56 +0800
Move files to its final postion in source structure. No code logic
changed!
0003-This-patch-is-the-main-work-to-to-support-differnt-a.patch.tar
Zhang, Xiantao wrote:
> These patches are based on commit
> 7060e1c92b504ac725e2ffbc91053c1dc684e685(last commit of Oct 8).
They don't apply on top of git head anymore, could you please rebase?
> Any comments are welcome!
I do appreciate your work towards portability. Could you also please
post
[EMAIL PROTECTED] wrote:
> Jim Paris wrote:
>> If I stop KVM in the monitor with "stop", wait a minute, and do
>> "cont", a Linux guest gives me a "BUG: soft lockup detected on
>> CPU#0". Is that expected behavior?
> We have the same behavior on s390 when running in a virtual
> environment. The iss
Change to inline style for easy review.
>From cdbc4c54cf65e46e5545fe44c9a31ae457385ee0 Mon Sep 17 00:00:00 2001
From: Zhang xiantao <[EMAIL PROTECTED]>
Date: Thu, 11 Oct 2007 16:42:46 +0800
Subject: [PATCH] Change kvm_x86_ops to kvm_ops, and make room for
structure kvm_arch_ops.
---
drivers/kvm/
>From 70477d03b238ca76c76d51a1b03f6cee8bb0965c Mon Sep 17 00:00:00 2001
From: Zhang xiantao <[EMAIL PROTECTED]>
Date: Thu, 11 Oct 2007 16:40:56 +0800
Move files to its final postion in source structure. No code logic
changed!
---
drivers/kvm/i8259.c | 450 --
drivers/kvm/i
Carsten Otte wrote:
> Zhang, Xiantao wrote:
>> These patches are based on commit
>> 7060e1c92b504ac725e2ffbc91053c1dc684e685(last commit of Oct 8).
> They don't apply on top of git head anymore, could you please rebase?
>
>> Any comments are welcome!
> I do appreciate your work towards portability
On Thu, Oct 11, 2007 at 10:40:47AM +0200, Laurent Vivier wrote:
> > There is work in progress for pci pass through capability. Besides
> > PCI it also required to have pv dma or 1-1 mapping between the
> > guest and the host. Both will be released in the following
> > month. NIC pass through work
Dong, Eddie wrote:
> [EMAIL PROTECTED] wrote:
>> Jim Paris wrote:
>>> If I stop KVM in the monitor with "stop", wait a minute, and do
>>> "cont", a Linux guest gives me a "BUG: soft lockup detected on
>>> CPU#0". Is that expected behavior?
>> We have the same behavior on s390 when running in a virt
Carsten Otte wrote:
> Thanks to Avi's continued review, we've got even more common code this
> time: KVM_CHECK_EXTENSION ioctl is now completely handled in kvm_main.c
> instead of having arch callbacks to check extensions. The architectures
> are expected to setup a bit mask named KVM_ARCH_EXTENSIO
Zhang, Xiantao wrote:
> 2. kvm_x86_ops-kvm_ops.patch. In order to adapt different
> architectures, we have to change it to an neutral name. kvm_ops maybe
> not the best name, but shouldn't introduce different meanings. In the
> third patch, we add a sub field struct kvm_arch_ops for arch-specific
Anthony Liguori wrote:
> The memory size is currently hardcoded into the linker script (end_of_memory).
> This prevents the memory size from being specified dynamically in kvmctl.
> This patch adds a PIO port that can be used to query the memory size in the
> tests.
>
>
Applied all three, thank
Avi Kivity wrote:
> The new capability bitmap moves the patch out of the "very trivial"
> realm. I removed those hunks and applied.
Thanks.
> Send more, the approach is clearly right. Leave things which require
> changes (like the capability bitmap) to the end, there's more than
> enough stuf
Anthony Liguori wrote:
> Sorry, I didn't guilt refresh before sending. I'll have to modify my
> patchbomb
> script to check for that to avoid this in the future.
>
> Some of the MMU functions take a struct kvm_vcpu even though they effect all
> VCPUs. This patch cleans up some of them to instead
Anthony Liguori wrote:
> This time, the biggest change is gpa_to_hpa. The translation of GPA to HPA
> does
> not depend on the VCPU state unlike GVA to GPA so there's no need to pass in
> the kvm_vcpu.
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>> Dong, Eddie wrote:
>>
>>> Avi Kivity wrote:
>>>
>>>
>
>
>> It's just like the guest kernel executing hlt. Why is there a
>> difference?
>>
>
> Current VP wake up logic thru INIT/SIPI doesn't support this when
> irqchip in kernel.
Christian Borntraeger wrote:
> Currently kvm provides hypercalls only for x86* architectures. To
> provide hypercall infrastructure for other kvm architectures I split
> kvm_para.h into a generic header file and architecture specific
> definitions.
> Currently there are definitions for s390 (experi
Currently kvm provides hypercalls only for x86* architectures. To
provide hypercall infrastructure for other kvm architectures I split
kvm_para.h into a generic header file and architecture specific
definitions.
Currently there are definitions for s390 (experimental, ABI not final,
and I still have
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> 2. kvm_x86_ops-kvm_ops.patch. In order to adapt different
>> architectures, we have to change it to an neutral name. kvm_ops maybe
>> not the best name, but shouldn't introduce different meanings. In the
>> third patch, we add a sub field struct kvm_arc
Muli Ben-Yehuda wrote:
> On Thu, Oct 11, 2007 at 10:40:47AM +0200, Laurent Vivier wrote:
>
>
>>> There is work in progress for pci pass through capability. Besides
>>> PCI it also required to have pv dma or 1-1 mapping between the
>>> guest and the host. Both will be released in the following
>
Christian Borntraeger wrote:
> ---
> include/asm-s390/kvm_para.h | 128
>
> include/asm-x86/kvm_para.h | 110 +
> include/linux/kvm_para.h| 112 --
> 3 files changed, 251 i
Avi Kivity wrote:
> Dong, Eddie wrote:
>
>> Avi:
>> Time to time, I see this error message, any typo exist?
>> thx,eddie
>>
>>
>> slab error in kmem_cache_destroy(): cache `kvm_rmap_desc': Can't free
>> all objects
>>
>> Call Trace:
>> [] kmem_cache_destroy+0x93/0xdc
>> [] :kvm:kvm_mmu_mo
> > +/* Return values for hypercalls */
> > +#define KVM_ENOSYS 1000
> >
>
> errno's can probably be in common code, right?
Yes, they can. Will move.
> I originally had one of these in my paravirt_ops implementation but
> quickly found that the code it produced was pretty ugly. I th
Zhang, Xiantao wrote:
> Avi Kivity wrote:
>
>> Zhang, Xiantao wrote:
>>
>>> 2. kvm_x86_ops-kvm_ops.patch. In order to adapt different
>>> architectures, we have to change it to an neutral name. kvm_ops maybe
>>> not the best name, but shouldn't introduce different meanings. In the
>>> thir
Christian Borntraeger wrote:
>
> I agree. It seems I can simply remove the kvm_hypercall macro.
>
> Here is the updated patch (without the s390 parts. Will send them later
> when ready) and the changes mentioned above.
>
> Avi, Anthony, comments?
>
It looks good to me.
Regards,
Anthony Liguor
Jerone Young wrote:
> This patch enables enable makefile in user for cross compile.
> This time is a proper git formatted patch.
>
>
Thanks, applied both.
--
error compiling committee.c: too many arguments to function
-
Zhao, Yunfeng wrote:
>
> I meet following error while compile latest kvm source code.
>
> ..
>
> make -C qemu
>
> make[1]: Entering directory
> `/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071010190122210/kvm-userspace/qemu'
>
> Makefile:3: config-host.mak: No such file or directory
>
> m
The same as under qemu/
[EMAIL PROTECTED] kvm-userspace]# ./configure
./configure: line 415: /tmp/qemu-conf-24955-17104-27972.c: No such file
or directory
ERROR: "/usr/bin/gcc34" either does not exist or does not work
I am using RHEL5, and compat-gcc-34-g77-3.4.6-4 has been installed on
it.
This e
if you put "set -x" at line 409 of configure, perhaps we can have more
information.
Laurent
Zhao, Yunfeng wrote:
> The same as under qemu/
> [EMAIL PROTECTED] kvm-userspace]# ./configure
> ./configure: line 415: /tmp/qemu-conf-24955-17104-27972.c: No such file
> or directory
> ERROR: "/usr/bin/g
Zhao, Yunfeng wrote:
> The same as under qemu/
> [EMAIL PROTECTED] kvm-userspace]# ./configure
> ./configure: line 415: /tmp/qemu-conf-24955-17104-27972.c: No such file
> or directory
> ERROR: "/usr/bin/gcc34" either does not exist or does not work
>
Looks like /tmp is full, of read-only, or so
My fault~ :(
I should spend more time to check the problem.
Don't know why the system lost the /tmp!
Thanks for your help!
Yunfeng
>-Original Message-
>From: Avi Kivity [mailto:[EMAIL PROTECTED]
>Sent: 2007年10月11日 22:38
>To: Zhao, Yunfeng
>Cc: kvm-devel@lists.sourceforge.net
>Subject: Re:
Steffen Winterfeldt wrote:
> Hi,
>
> sorry for the delay, but I've been on vacation. :-)
>
No worries :-)
>> You're right. Good catch!
>>
>
> Actually that is not true. 'mov eax,ss' does implicitly clear the upper
> 16 bits (both processor docs and hardware agree here).
>
I wasn't ab
Hello Dong and others,
thanks for the replies. I was trying to get KVM up with latest kernel, but
didn't immediately succeed. I have it built with the instructions from a
previous reply and it seemed OK, but I haven't had a chance to try it out
yet.
As for testing the time shift: To us the vi
Dor Laor wrote:
> Cam Macdonell wrote:
>
> You may choose the interactivity improvements:in
> http://kvm.qumranet.com/kvmwiki/TODO
> Dor
Thanks Dor, I'll look into it. Beyond the description, can you
elaborate on the problem with frame rate during interactivity? Is the a
simple test that re
Carsten Otte/Germany/[EMAIL PROTECTED] wrote on 10/11/2007 12:57:38 PM:
> Dong, Eddie wrote:
> > [EMAIL PROTECTED] wrote:
> >> Jim Paris wrote:
> >>> If I stop KVM in the monitor with "stop", wait a minute, and do
> >>> "cont", a Linux guest gives me a "BUG: soft lockup detected on
> >>> CPU#0". I
This patch splits kvm_vcpu_ioctl into archtecture independent parts, and
x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
Common ioctls for all architectures are:
KVM_RUN, KVM_GET/SET_(S-)REGS, KVM_TRANSLATE, KVM_INTERRUPT,
KVM_DEBUG_GUEST, KVM_SET_SIGNAL_MASK, KVM_GET/SET_FPU
Note th
Carsten Otte wrote:
> This patch splits kvm_vcpu_ioctl into archtecture independent parts, and
> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
>
> Common ioctls for all architectures are:
> KVM_RUN, KVM_GET/SET_(S-)REGS, KVM_TRANSLATE, KVM_INTERRUPT,
> KVM_DEBUG_GUEST, KVM_SET_SIGNA
Carsten Otte wrote:
> This patch splits kvm_vcpu_ioctl into archtecture independent parts, and
> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
>
>
> static inline int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva,
> Index: kvm/drivers/kvm/kvm_main.c
>
Avi Kivity wrote:
> This is wrong -- kvm_main.c calls vmalloc() so this is needed. The fact
> that it is included by something else doesn't mean we can remove it; we
> don't want to depend on random #includes within header files.
>
> Only remove a #include if nothing within the including file d
Avi Kivity wrote:
> Applied, thanks. I renamed kvm_vcpu_load() and kvm_vcpu_put() back to
> vcpu_load() and vcpu_put() in order to keep the patch small and simple,
> and because I'm emotionally attached to the original names.
Oh, I think I had a very good reason for renaming it: it's no longer
Dor,
I ran some netperf tests with your PV
virtio drivers, along with some Xen PV cases
and a few others for comparison. I thought you
(and the list) might be interested in the numbers.
I am going to start looking for bottlenecks, unless
you need help with the new hypercall updates.
I'll re-run
Now that we have userspace memory allocation, I wanted to play with ballooning.
The idea is that when a guest "balloons" down, we simply unpin the underlying
physical memory and the host kernel may or may not swap it. To reclaim
ballooned memory, the guest can just start using it and we'll pin it
Anthony Liguori wrote:
> Now that we have userspace memory allocation, I wanted to play with
> ballooning.
> The idea is that when a guest "balloons" down, we simply unpin the underlying
> physical memory and the host kernel may or may not swap it. To reclaim
> ballooned memory, the guest can jus
Izik Eidus wrote:
>> static void page_header_update_slot(struct kvm *kvm, void *pte,
>> gpa_t gpa)
>> {
>> int slot = memslot_id(kvm, gfn_to_memslot(kvm, gpa >> PAGE_SHIFT));
>>
>> -
>>
>>
> kvm_memory_slot
>
> heh,
Anthony Liguori wrote:
Izik Eidus wrote:
static void page_header_update_slot(struct kvm *kvm, void *pte,
gpa_t gpa)
{
int slot = memslot_id(kvm, gfn_to_memslot(kvm, gpa >>
PAGE_SHIFT));
-
kvm_memory_slot
he
James Dykman wrote:
> Dor,
>
> I ran some netperf tests with your PV
> virtio drivers, along with some Xen PV cases
> and a few others for comparison. I thought you
> (and the list) might be interested in the numbers.
>
>
Thanks for the tests it indeed interesting.
Actually except for a small
The idea being that kvm_read_guest_page() will effectively pin the page
and put_page() has the effect of unpinning it? It seems to me that we
should be using page_cache_release()'ing since we're not just
get_page()'ing the memory. I may be wrong though.
Both of these are an optimization th
>>
>> Current VP wake up logic thru INIT/SIPI doesn't support this when
>> irqchip in kernel.
>>
>>
>
> Doesn't this code imply that waiting for SIPI is supported?
It is supported to wake up VCPU in kernel, but can't wake up the VCPU
in user level since irqchip_in_kernel is TRUE here. vcpu->m
Kay Hayen wrote:
> Hello Dong and others,
>
> thanks for the replies. I was trying to get KVM up with latest
> kernel, but didn't immediately succeed. I have it built with the
> instructions from a previous reply and it seemed OK, but I haven't
> had a chance to try it out yet.
>
> As for testing
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Avi Kivity wrote:
>>
>>> Zhang, Xiantao wrote:
>>>
2. kvm_x86_ops-kvm_ops.patch. In order to adapt different
architectures, we have to change it to an neutral name. kvm_ops
maybe not the best name, but shouldn't introduce different
Hi,Avi
With latest kvm commits, the SMP linux guests causes host soft lock issues can
not be reproduced on my machine.
Have you fixed it?
Thanks
Yunfeng
>-Original Message-
>From: Avi Kivity [mailto:[EMAIL PROTECTED]
>Sent: 2007年10月9日 18:19
>To: Zhao, Yunfeng
>Cc: kvm-devel
>Subject: Re
Zhao, Yunfeng wrote:
> Hi,Avi
> With latest kvm commits, the SMP linux guests causes host soft lock issues
> can not be reproduced on my machine.
> Have you fixed it?
>
>
Not intentionally...
Maybe the rmap fix is somehow responsible.
--
Do not meddle in the internals of kernels, for they
Dong, Eddie wrote:
>>> Current VP wake up logic thru INIT/SIPI doesn't support this when
>>> irqchip in kernel.
>>>
>>>
>>>
>> Doesn't this code imply that waiting for SIPI is supported?
>>
>
> It is supported to wake up VCPU in kernel, but can't wake up the VCPU
> in user level since
Carsten Otte wrote:
> Avi Kivity wrote:
>> Applied, thanks. I renamed kvm_vcpu_load() and kvm_vcpu_put() back
>> to vcpu_load() and vcpu_put() in order to keep the patch small and
>> simple, and because I'm emotionally attached to the original names.
> Oh, I think I had a very good reason for rena
Anthony Liguori wrote:
> Now that we have userspace memory allocation, I wanted to play with
> ballooning.
> The idea is that when a guest "balloons" down, we simply unpin the underlying
> physical memory and the host kernel may or may not swap it. To reclaim
> ballooned memory, the guest can jus
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>>>
>>> x86 will continue to use kvm_x86_ops for that purposes. But other
>>> archs should not.
>>>
>>> x86 will use both mechanisms: first, linkage will select the x86
>>> function, and then kvm_x86_ops will be used to select the
>>> implementation dep
Bugs item #1812043, was opened at 2007-10-12 14:41
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=1812043&group_id=180599
Please note that this message will contain a full copy
Zhang, Xiantao wrote:
>>
>> x86 will continue to use kvm_x86_ops for that purposes. But other
>> archs should not.
>>
>> x86 will use both mechanisms: first, linkage will select the x86
>> function, and then kvm_x86_ops will be used to select the
>> implementation dependent code. The two levels a
67 matches
Mail list logo
