[kvm-devel] [ kvm-Bugs-1812043 ] Cannot boot 32bit smp RHEL5.1 guest
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 of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot boot 32bit smp RHEL5.1 guest Initial Comment: 32bit smp RHEL5.1 guest cannot boot on 32bit host and 64bit host. With "-no-kvm-irqchip" it also fails. But if booted it with UP or with "-no-kvm", it has no any problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&group_id=180599 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch] [0/3] Patches to support new architectures.
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 dependent code. The two levels are very different as >>> kvm_x86_ops is very low level and x86 specific. >>> >> Hi Avi, >> Maybe linkage is a better choice. But if we need to maintain two >> different implmentation for different archs, it may introduce >> unnecessary effort. In addition, I can't figure out any >> disadvantages with function pointers, moreover, it makes source >> uniform for all architectures, though it is not very necessary. >> > > Linkage is more efficient (though I don't think we'll be able to > measure the difference) and is also the traditional way of doing > things in Linux. > > I don't see why it causes extra effort. Can you explain? I orgirnally mean we have to wrap all functions related to kvm_x86_ops. But seems it doesn't introduce extra maintain effort, if other architectures implment these functions directly. Good method! Thanks Xiantao - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch] [0/3] Patches to support new architectures.
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 are very different as >> kvm_x86_ops is very low level and x86 specific. >> > Hi Avi, > Maybe linkage is a better choice. But if we need to maintain two > different implmentation for different archs, it may introduce > unnecessary effort. > In addition, I can't figure out any disadvantages with function > pointers, moreover, it makes source uniform for all architectures, > though it is not very necessary. > Linkage is more efficient (though I don't think we'll be able to measure the difference) and is also the traditional way of doing things in Linux. I don't see why it causes extra effort. Can you explain? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Expose infrastructure for unpinning guest memory
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 just start using it and we'll pin it on > demand. > > The following patch is a stab at providing the right infrastructure for > pinning > and automatic repinning. I don't have a lot of comfort in the MMU code so I > thought I'd get some feedback before going much further. > > gpa_to_hpa is a little awkward to hook, but it seems like the right place in > the > code. I'm most uncertain about the SMP safety of the unpinning. Presumably, > I have to hold the kvm lock around the mmu_unshadow and page_cache release to > ensure that another VCPU doesn't fault the page back in after mmu_unshadow? > > One we have true swapping capabilities (which imply ability for the kernel to remove a page from the shadow page tables) you can unpin by calling munmap() or madvise(MADV_REMOVE) on the pages to be unpinned. Other than that the approach seems right. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vcpu_ioctl v1
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 renaming it: it's no longer > static, and thus part of the kernel's global namespace in case kvm is > built-in. As far as I know, modules are expected to prefix any symbol > they use with their module name. > I am sorry for the emotional part of it, I tend to stick to old names > too once I got used to them. > In case you decide you want kvm_vcpu_load/put again, let me know so > that I can supply a patch on top of git that renames it. I agree 100%, I'm just using the "keep the patch dead simple" excuse to delay the change. We can have a 'add kvm_ prefix' patch round later. Let's complete the separation first. There are some bigger offenders too, like set_crX(), which don't even start with the magic V and are exported to modules. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kernel device reset support
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 irqchip_in_kernel is TRUE here. vcpu->mp_state > doesn't export to user level. > > We never sleep in user level if irqchip_in_kernel(). So the thread will eventually go back to kernel mode. >> You can put a goto to the top of the loop to redo the mmu reload. In >> any case you need to do that because you don't want to execute >> the reset >> code with interrupts and preemption disabled. >> > > A goto cross function? It is too aggresive and bad code style IMO. > The vcpu->request check is in __vcpu_run, while entering block > state is in its parent function kvm_vcpu_ioctl_run. > > goto the label 'again' in __vcpu_run(), which has the call to kvm_mmu_reload(). > But if you want, we can return a special value, > say REQUEST_INTERNAL_LOOP, to > kvm_vcpu_ioctl_run and let kvm_vcpu_ioctl_run use sepcial logic > to do goto within function if it see the special return value > REQUEST_INTERNAL_LOOP. But is it cleaner? > > Also we will add more kernel to user EXIT reason, such as RESET request > from kernel sensored guest tripple fault etc. > > There is already a triple fault exit code. >>> The VCPU may be executing in kernel still, which may modify kernel >>> device state. E.g. A VCPU may be doing PIO emulating. >>> >>> >>> >> In that case we will wait when taking kvm->lock. >> > > Lock doesn't help. Lock can only avoid no 2+ modifcation > in same time. But what we care if all other VCPUs can't > do modification after BSP do device reset. > It is different semantics. > > Maybe you are still arguing it is the AP who do RESET ops. > Let us go to next discussion first. > > We first halt all vcpus, then take the lock. So: - other processors won't start after the device reset because they are halted - we won't do the reset concurrently with other processors because of the lock >>> If BSP reset the kernel devices earlier than the VCPU modify the >>> device state, we are in trouble. >>> >>> No, VCPU0 (BSP) is current VCPU (though you don't have the current >>> vcpu parameter explicitly) like mentioned in previous mail and >>> as pre-requirement of user level change. Please refer my abswer >>> above of this mail. >>> >>> >>> >> We can't rely on user space not to cause host kernel corruption. >> > > ??? > > Even an AP trigger RESET, it just sets a reset_request flag in user > level. > It is another VCPU who will execute RESET operation. > > It seems the argument is who should do the RESET operation, > say RST_CPU. BSP only or AP too. For me, since after RESET > only BSP can execute, and the thread executing > qemu_system_reset will continously execute > (after RESET kernel) per current Qemu code, so what we can do is: > > 1: RST_CPU=BSP. Then BSP does qemu_system_reset, or > 2: RST_CPU = AP, say RAP, does qemu_system_reset, user level > then > need to block RAP after qemu_system_reset and wake up BSP to take over. > A point here we can't blcok RAP in case 2 at kernel RESET time, > since > kernel RESET may be not the last step of qemu_system_reset. It may go > to kernel again. > > If we go with #1, just 1 line change as in my previous mail. > If we go with #2, we have to add a new ABI for the AP to enter > kernel > wait for INIT/SIPI/SIPI state, otherwise normal INIT/SIPI/SIPI couldn't > wake it up. > > I see much complicate in #2 while #1 has same functionality but > simple. > > My view is: - vcpu threads never sleep in userspace. they will always eventually end up in the kernel so we can stop or restart them there - reset is a platform API so it can't be dependent on which vcpu thread executes it (if any; it may be executed from an unrelated thread, remember we plan to separate the qemu signal handling code into a separate thread) - we already have a way to send messages to other vcpus So it seems to me everything is in place to make it fairly simple. I'll try writing a patch that does what I mean and post it. Either I'll convince you that in-kernel is simpler, or I'll convince myself that it is harder. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-45 problems
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 are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-45 problems
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: [kvm-devel] kvm-45 problems > >Avi Kivity wrote: >> Zhao, Yunfeng wrote: >> >>> We run some booting multiple guest tests in our nightly testing. >>> Like booting two UP windows guests, booting one UP linux guest and one UP >windows guest, and booting 4 UP linux guests. >>> The first two cases have no problem in our testing. >>> And booting 4 UP linux guests may crash host, but this problem doesn't >>> happen >very time. If the problem didn't happen, linux guest can be log in without any >problem. >>> >>> For smp guest, we meet a problem that booting linux guest with 4 vcpus >>> causes >soft lock error on host. Once this error happened, qemu process also could not >be killed. >>> >>> Our linux guests are using 2.6.9, 2.6.16, and 2.6.23 kernels. >>> >>> >>> >> >> This may be due to NMIs or MCEs. Is it possible your machine is >> receiving them? >> > > >I pushed a fix for the NMI issue. Can you check if it fixes your hangs? > > >-- >error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch] [0/3] Patches to support new architectures.
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 meanings. In the third patch, we add a sub field struct kvm_arch_ops for arch-specific ops. That is, different CPU archs can define its arch-specific ops for its special need. IMO, we should treat x86, IA64, ppc etc as different archtiectures, other than see vmx, svm as different archs. svm and vmx should be two different virtualization approaches for x86 arch from the point view of platforms. >>> ia64, ppc, and s390 don't need to select an implementation at >>> runtime (since each have just one instruction set) so they don't >>> need function pointers. Instead we should use linkage (different >>> functions for each arch, but with the same names). Kbuild will >>> select the right files to compile depending on arch. >>> >> >> For x86 side, how to handle the co-existence of vmx and svm ? For >> example, in a release linux kernel which supports KVM, how to know >> it will be installed to Intel or AMD platforms ? If we determin it in >> advance, we have to compile them all in at one time, but it maybe >> difficult for current kvm code to implement. >> > > 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 are very different as > kvm_x86_ops is very low level and x86 specific. Hi Avi, Maybe linkage is a better choice. But if we need to maintain two different implmentation for different archs, it may introduce unnecessary effort. In addition, I can't figure out any disadvantages with function pointers, moreover, it makes source uniform for all architectures, though it is not very necessary. Thanks Xiantao - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Guest Time Question
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 the time shift: To us the virtual machine would be > like another hardware baseline to verify. So we will have to do that > to test the time correctness. What to do? > > Sending time stamped broadcast or multicast messages may well do the > trick, I have yet to look on how the network stack or the guest and > host work together in paravirtualization with KVM. > > Also I would not be sure what a 0.1% shift would be. From what do you > mean the percentage? Or is that a typo and you would mean 0.1 ms ? > > Best regards, > Kay Hayen > >>> So in FAQ and Wiki I didn't find how to make the guest use host >>> time. Is that possible at all? For VMWare it is said that clock=pit >>> would help, but that seemed to be no change. >>> >>> Can you please point me to what to do? >>> >>> Best regards, >>> Kay Hayen >> >> If you can get latest KVM up + clock=pit, I bet you will get a much >> much accurate guest time. If you still see > 0.1% shift, please file >> a bug. thx,eddie I mean wall clock shift will be <0.1%. For network packet, it is different with that in native since a VCPU may be descheduled. But it is same even in native when you compare a fast box vs. slow box. thx,eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kernel device reset support
>> >> 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->mp_state doesn't export to user level. >> > > You can put a goto to the top of the loop to redo the mmu reload. In > any case you need to do that because you don't want to execute > the reset > code with interrupts and preemption disabled. A goto cross function? It is too aggresive and bad code style IMO. The vcpu->request check is in __vcpu_run, while entering block state is in its parent function kvm_vcpu_ioctl_run. But if you want, we can return a special value, say REQUEST_INTERNAL_LOOP, to kvm_vcpu_ioctl_run and let kvm_vcpu_ioctl_run use sepcial logic to do goto within function if it see the special return value REQUEST_INTERNAL_LOOP. But is it cleaner? Also we will add more kernel to user EXIT reason, such as RESET request from kernel sensored guest tripple fault etc. >> >> The VCPU may be executing in kernel still, which may modify kernel >> device state. E.g. A VCPU may be doing PIO emulating. >> >> > > In that case we will wait when taking kvm->lock. Lock doesn't help. Lock can only avoid no 2+ modifcation in same time. But what we care if all other VCPUs can't do modification after BSP do device reset. It is different semantics. Maybe you are still arguing it is the AP who do RESET ops. Let us go to next discussion first. > >> If BSP reset the kernel devices earlier than the VCPU modify the >> device state, we are in trouble. >> >> No, VCPU0 (BSP) is current VCPU (though you don't have the current >> vcpu parameter explicitly) like mentioned in previous mail and >> as pre-requirement of user level change. Please refer my abswer >> above of this mail. >> >> > > We can't rely on user space not to cause host kernel corruption. ??? Even an AP trigger RESET, it just sets a reset_request flag in user level. It is another VCPU who will execute RESET operation. It seems the argument is who should do the RESET operation, say RST_CPU. BSP only or AP too. For me, since after RESET only BSP can execute, and the thread executing qemu_system_reset will continously execute (after RESET kernel) per current Qemu code, so what we can do is: 1: RST_CPU=BSP. Then BSP does qemu_system_reset, or 2: RST_CPU = AP, say RAP, does qemu_system_reset, user level then need to block RAP after qemu_system_reset and wake up BSP to take over. A point here we can't blcok RAP in case 2 at kernel RESET time, since kernel RESET may be not the last step of qemu_system_reset. It may go to kernel again. If we go with #1, just 1 line change as in my previous mail. If we go with #2, we have to add a new ABI for the AP to enter kernel wait for INIT/SIPI/SIPI state, otherwise normal INIT/SIPI/SIPI couldn't wake it up. I see much complicate in #2 while #1 has same functionality but simple. thanks, eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Expose infrastructure for unpinning guest memory
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 though. It's not strictly needed for
what I'm after since in the case of ballooning, there's no reason why
someone would be calling kvm_read_guest_page() on the ballooned memory.
secoend, is hacking the rmap to do reverse mapping to every present
pte and put_page() the pages at rmap_remove()
and this about all, to make this work.
If I understand you correctly, this is to unpin the page whenever it is
removed from the rmap? That would certainly be useful but it's still an
optimization. The other obvious optimization to me would be to not use
get_user_pages() on all memory to start with and instead, allow pages to
be faulted in on use. This is particularly useful for creating a VM
with a very large amount of memory, and immediately ballooning down.
That way the large amount of memory doesn't need to be present to actual
spawn the guest.
Regards,
Anthony Liguori
Izik idea is towards general guest swapping capability. The first step
is just to increase the
reference count of the rmapped pages. The second is to change the size
of the shadow pages
table as function of the guest memory usage and the third is to get
notifications from Linux
about pte state changes.
btw: I have an unmerged balloon code (guest & host) with the old kernel
mapping.
The guest part may be still valid for the userspace allocation.
Attaching it.
Dor.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
/*
* KVM guest balloon driver
*
* Copyright (C) 2007, Qumranet, Inc., Dor Laor <[EMAIL PROTECTED]>
*
* This work is licensed under the terms of the GNU GPL, version 2. See
* the COPYING file in the top-level directory.
*/
#include "../kvm.h"
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
MODULE_AUTHOR ("Dor Laor");
MODULE_DESCRIPTION ("Implements guest ballooning support");
MODULE_LICENSE("GPL");
MODULE_VERSION("1");
#define KVM_BALLOON_MINOR MISC_DYNAMIC_MINOR
static LIST_HEAD(balloon_plist);
static int balloon_size = 0;
static DEFINE_SPINLOCK(balloon_plist_lock);
static gfn_t balloon_shared_gfn;
struct balloon_page {
struct page *bpage;
struct list_head bp_list;
};
static int kvm_trigger_balloon_op(int npages)
{
unsigned long ret;
ret = kvm_hypercall2(__NR_hypercall_balloon, balloon_shared_gfn,
npages);
WARN_ON(ret);
printk(KERN_DEBUG "%s:hypercall ret: %lx\n", __FUNCTION__, ret);
return ret;
}
static int kvm_balloon_inflate(unsigned long *shared_page_addr, int npages)
{
LIST_HEAD(tmp_list);
struct balloon_page *node, *tmp;
u32 *pfn = (u32*)shared_page_addr;
int allocated = 0;
int i, r = -ENOMEM;
for (i = 0; i < npages; i++) {
node = kzalloc(sizeof(struct balloon_page), GFP_KERNEL);
if (!node)
goto out_free;
node->bpage = alloc_page(GFP_HIGHUSER | __GFP_ZERO);
if (!node->bpage) {
kfree(node);
goto out_free;
}
list_add(&node->bp_list, &tmp_list);
allocated++;
*pfn++ = page_to_pfn(node->bpage);
}
spin_lock(&balloon_plist_lock);
r = kvm_trigger_balloon_op(npages);
if (r < 0) {
printk(KERN_DEBUG "%s: got kvm_trigger_balloon_op res=%d\n",
__FUNCTION__, r);
spin_unlock(&balloon_plist_lock);
goto out_free;
}
list_splice(&tmp_list, &balloon_plist);
balloon_size += allocated;
printk(KERN_DEBUG "%s: current balloon size=%d\n", __FUNCTION__,
balloon_size);
spin_unlock(&balloon_plist_lock);
return allocated;
out_free:
list_for_each_entry_safe(node, tmp, &tmp_list, bp_list) {
__free_page(node->bpage);
list_del(&node->bp_list);
kfree(node);
}
return r;
}
static int kvm_balloon_deflate(unsigned long *shared_page_addr, int npages)
{
LIST_HEAD(tmp_list);
struct balloon_page *node, *tmp;
u32 *pfn = (u32*)shared_page_addr;
int dealloca
Re: [kvm-devel] PV network performance comparison
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 optimization (receiving several msgs from the tap and sending a single irq) I haven't had the time to optimize the code. It's also interesting to check what lguest is doing since the qemu path is not polished, also lguest has newer virtio drivers. > I am going to start looking for bottlenecks, unless > you need help with the new hypercall updates. > I'll re-run when that is available. > > Any help would be great. I also need to move towards the latest virtio patch that includes a change in the shared memory and pci like config space. I planned on doing this starting mid next week. W.r.t performance the following can improve: - Avi's shorten latency tap patch - Using scatter gather in qemu tap That's why using bigger pkts don't help performance. - Minimize guest tx hypercalls - Running oprofile - Host side kernel driver. Thanks, Dor. > Jim > > Tests were run with Netperf-2.4.3, TCP Socket > buffers were 256k. All of the tests were run with > netserver in the guest, netperf in the host/dom0. > No bridge was used. > > Hardware: IBM HS21 blade > Dual Xeon w/HT @ 1.6GHz, 4GB > > The host/Dom0 configuration: > kvm.*: > Host is 32 bit Ubuntu 7.04 server running > Dor's 2.6.22-rc3 kernel. > xen.*: > Dom0 is 32 bit Ubuntu 7.04 server running > the 2.6.18 kernel from xen3.1 > > The guest configurations: > All guests/domUs are 512MB, 1 CPU > kvm.rtl: (KVM with emulated RTL8029) > Fedora 7 32 bit guest > Standard 2.6.21-1.3194.fc7 kernel > kvm.pv: (KVM w/Dor's paravirt drivers) > Fedora 7 32 bit guest running > Dor's 2.6.22-rc3 kernel. > xen.pv: (Xen paravirt) > Ubuntu 7.04 server w/2.6.18-xen kernel > xen.um: (Xen HVM with unmodified drivers) > Ubuntu 7.04 server w/2.6.18-xen kernel, > unmodified drivers compiled from xen3.1 > kvm.lo: (Host loopback) > > TCP REQUEST/RESPONSE (Trans. Rate per sec) > size kvm.rtl kvm.pvxen.pvxen.umkvm.lo > 1 2191.47 9533.74 18052.37 13593.58 42400.73 > 642184.30 9518.13 17979.93 13557.98 42260.53 > 128 2177.52 9482.45 17940.08 13588.54 40983.90 > 256 2160.49 9465.97 17788.21 13492.42 41170.45 > 512 2130.99 9403.33 17655.11 13489.64 40765.26 > 1024 2074.85 9204.90 17293.06 13572.01 39437.78 > 2048 416.18 4750.41 12907.57 11571.07 37252.42 > 4096 265.22 3691.90 10990.67 9943.64 31905.03 > 8192 116.80 1892.25 8439.83 6604.64 24397.95 > 16384 92.06 1004.58 4535.86 3924.68 17460.30 > > TCP STREAM (Throughput 10^6bits/sec) > sizekvm.rtl kvm.pv xen.pv xen.um kvm.lo >204833.06 507.21 555.94 1442.38 5409.73 >409633.16 526.75 848.26 2359.42 6152.48 >819233.13 527.99 997.69 2418.87 7267.73 > 1638433.08 525.95 1107.64 2379.50 8434.29 > 3276833.13 525.38 1199.08 2375.81 8857.09 > 6553633.20 523.39 1255.33 2473.92 9248.35 > 13107233.11 520.87 1292.54 2605.49 8559.21 > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Expose infrastructure for unpinning guest memory
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
heh, i am working on similir patch, and our gfn_to_page and the
change to kvm_memory_slot even by varible names :)
Ah, fantastic :-) Care to share what you currently have?
here it is :)
few things you have to do to make this work:
make gfn_to_page safe always function (return bad_page in case of
failure, i have patch for this if you want)
That seems pretty obvious. No reason not to have that committed now.
it is include in the patch that i sent you
hacking the kvm_read_guest_page / kvm_write_guest_page
kvm_clear_guest_page to do put_page after the usage of the page
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 though. It's not strictly needed
for what I'm after since in the case of ballooning, there's no reason
why someone would be calling kvm_read_guest_page() on the ballooned
memory.
ohhh, gfn_to_page do get_page to the pages ( this is called by
get_user_pages automaticly), this is the only way the system can make
sure the page wont be swapped by when you are using it
and if we will insert swapped page to the guest, we will have memory
corraption...
therefor each page that we get by gfn_to_page must be put_paged after
using it
to make it easy, gfn_to_page should do get_page even on normal kernel
allocated pages
(btw you have nothing to worry about, if the page is swapped,
get_users_pages walk on the pte and get it out for us)
secoend, is hacking the rmap to do reverse mapping to every present
pte and put_page() the pages at rmap_remove()
and this about all, to make this work.
If I understand you correctly, this is to unpin the page whenever it
is removed from the rmap? That would certainly be useful but it's
still an optimization. The other obvious optimization to me would be
to not use get_user_pages() on all memory to start with and instead,
allow pages to be faulted in on use. This is particularly useful for
creating a VM with a very large amount of memory, and immediately
ballooning down. That way the large amount of memory doesn't need to
be present to actual spawn the guest.
we must to call get_user_pages, beacuse each page that we dont hold the
refernec (page->_count) can point to diffrent virtual address any moment
infact with this way, in kvmctl, we can remove the memset(...) on all
the memory ( i did this just beacuse of some lazyness/copy on write/how
you want to call this, mechanisem that linux have), beacuse now each
call to gfn_to_page return the right virtual address of the physical
guest page.
the patch is here,
all what needed to make it work with swapping is runing rmap on EVERY
present pages ( now it run on just writeable pages, witch mean that
other pages are not protected from being swapped )
you can try silly swapping, by removing the put_page from rmap_remove
and from set_pte_common() function
btw, i didnt some ugly thing now to get you the patch, so i dont sure if
it will be applied, or some parts might be missing, i am sorry for this,
but i have no time to check it now
i will do cleanup to the patchs when the rmap will be ready...
Regards,
Anthony Liguori
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 4ab487c..e7df8fc 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -409,6 +409,7 @@ struct kvm_memory_slot {
unsigned long *rmap;
unsigned long *dirty_bitmap;
int user_alloc; /* user allocated memory */
+ unsigned long userspace_addr;
};
@@ -561,8 +562,9 @@ static inline int is_error_hpa(hpa_t hpa) { return hpa >> HPA_MSB; }
hpa_t gva_to_hpa(struct kvm_vcpu *vcpu, gva_t gva);
struct page *gva_to_page(struct kvm_vcpu *vcpu, gva_t gva);
-extern hpa_t bad_page_address;
+extern struct page *bad_page;
+int is_error_page(struct page *page);
gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn);
struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 0b2894a..dde8497 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -325,13 +325,13 @@ static void kvm_free_userspace_physmem(struct kvm_memory_slot *free)
{
int i;
- for (i = 0; i < free->npages; ++i) {
+ /*for (i = 0; i < free->npages; ++i) {
if (free->phys_mem[i]) {
if (!PageReserved(free->phys_mem[i]))
SetPageDirty(free->phys_mem[i]);
page_cache_release(free->phys_mem[i]);
}
- }
+ }*/
}
@@ -773,19 +773,8 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
memset(new.phys_mem, 0,
Re: [kvm-devel] [RFC] Expose infrastructure for unpinning guest memory
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, i am working on similir patch, and our gfn_to_page and the change
> to kvm_memory_slot even by varible names :)
Ah, fantastic :-) Care to share what you currently have?
> few things you have to do to make this work:
> make gfn_to_page safe always function (return bad_page in case of
> failure, i have patch for this if you want)
That seems pretty obvious. No reason not to have that committed now.
> hacking the kvm_read_guest_page / kvm_write_guest_page
> kvm_clear_guest_page to do put_page after the usage of the page
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 though. It's not strictly needed for
what I'm after since in the case of ballooning, there's no reason why
someone would be calling kvm_read_guest_page() on the ballooned memory.
>
> secoend, is hacking the rmap to do reverse mapping to every present
> pte and put_page() the pages at rmap_remove()
> and this about all, to make this work.
If I understand you correctly, this is to unpin the page whenever it is
removed from the rmap? That would certainly be useful but it's still an
optimization. The other obvious optimization to me would be to not use
get_user_pages() on all memory to start with and instead, allow pages to
be faulted in on use. This is particularly useful for creating a VM
with a very large amount of memory, and immediately ballooning down.
That way the large amount of memory doesn't need to be present to actual
spawn the guest.
Regards,
Anthony Liguori
>
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Expose infrastructure for unpinning guest memory
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 just start using it and we'll pin it on
> demand.
>
> The following patch is a stab at providing the right infrastructure for
> pinning
> and automatic repinning. I don't have a lot of comfort in the MMU code so I
> thought I'd get some feedback before going much further.
>
> gpa_to_hpa is a little awkward to hook, but it seems like the right place in
> the
> code. I'm most uncertain about the SMP safety of the unpinning. Presumably,
> I have to hold the kvm lock around the mmu_unshadow and page_cache release to
> ensure that another VCPU doesn't fault the page back in after mmu_unshadow?
>
> Feedback would be greatly appreciated!
>
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index 4a52d6e..8abe770 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -409,6 +409,7 @@ struct kvm_memory_slot {
> unsigned long *rmap;
> unsigned long *dirty_bitmap;
> int user_alloc; /* user allocated memory */
> + unsigned long userspace_addr;
> };
>
> struct kvm {
> @@ -652,6 +653,7 @@ int kvm_mmu_unprotect_page_virt(struct kvm_vcpu *vcpu,
> gva_t gva);
> void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
> int kvm_mmu_load(struct kvm_vcpu *vcpu);
> void kvm_mmu_unload(struct kvm_vcpu *vcpu);
> +int kvm_mmu_unpin(struct kvm *kvm, gfn_t gfn);
>
> int kvm_emulate_hypercall(struct kvm_vcpu *vcpu);
>
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index a0f8366..74105d1 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -774,6 +774,7 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
> unsigned long pages_num;
>
> new.user_alloc = 1;
> + new.userspace_addr = mem->userspace_addr;
> down_read(¤t->mm->mmap_sem);
>
> pages_num = get_user_pages(current, current->mm,
> @@ -1049,12 +1050,36 @@ struct kvm_memory_slot *gfn_to_memslot(struct kvm
> *kvm, gfn_t gfn)
> struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
> {
> struct kvm_memory_slot *slot;
> + struct page *page;
> + uint64_t slot_index;
>
> gfn = unalias_gfn(kvm, gfn);
> slot = __gfn_to_memslot(kvm, gfn);
> if (!slot)
> return NULL;
> - return slot->phys_mem[gfn - slot->base_gfn];
> +
> + slot_index = gfn - slot->base_gfn;
> + page = slot->phys_mem[slot_index];
> + if (unlikely(page == NULL)) {
> + unsigned long pages_num;
> +
> + down_read(¤t->mm->mmap_sem);
> +
> + pages_num = get_user_pages(current, current->mm,
> +slot->userspace_addr +
> +(slot_index << PAGE_SHIFT),
> +1, 1, 0, &slot->phys_mem[slot_index],
> +NULL);
> +
> + up_read(¤t->mm->mmap_sem);
> +
> + if (pages_num != 1)
> + page = NULL;
> + else
> + page = slot->phys_mem[slot_index];
> + }
> +
> + return page;
> }
> EXPORT_SYMBOL_GPL(gfn_to_page);
>
> diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
> index f52604a..1820816 100644
> --- a/drivers/kvm/mmu.c
> +++ b/drivers/kvm/mmu.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -820,6 +821,33 @@ static void mmu_unshadow(struct kvm *kvm, gfn_t gfn)
> }
> }
>
> +int kvm_mmu_unpin(struct kvm *kvm, gfn_t gfn)
> +{
> + struct kvm_memory_slot *slot;
> + struct page *page;
> +
> + /* FIXME for each active vcpu */
> +
> + gfn = unalias_gfn(kvm, gfn);
> + slot = gfn_to_memslot(kvm, gfn);
> + if (!gfn)
> + return -EINVAL;
> +
> + /* FIXME: do we need to hold a lock here? */
> +
> + /* Remove page from shadow MMU and unpin page */
> + mmu_unshadow(kvm, gfn);
> + page = slot->phys_mem[gfn - slot->base_gfn];
> + if (page) {
> + if (!PageReserved(page))
> + SetPageDirty(page);
> + page_cache_release(page);
> + slot->phys_mem[gfn - slot->base_gfn] = NULL;
> + }
> +
> + return 0;
> +}
> +
> 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, i am working on similir patch, and our gfn_to_page and the change
to kvm_memory_slot even by varible names :)
few things you have to do to make this work:
make gfn_to_page safe always f
[kvm-devel] [RFC] Expose infrastructure for unpinning guest memory
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 on demand.
The following patch is a stab at providing the right infrastructure for pinning
and automatic repinning. I don't have a lot of comfort in the MMU code so I
thought I'd get some feedback before going much further.
gpa_to_hpa is a little awkward to hook, but it seems like the right place in the
code. I'm most uncertain about the SMP safety of the unpinning. Presumably,
I have to hold the kvm lock around the mmu_unshadow and page_cache release to
ensure that another VCPU doesn't fault the page back in after mmu_unshadow?
Feedback would be greatly appreciated!
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 4a52d6e..8abe770 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -409,6 +409,7 @@ struct kvm_memory_slot {
unsigned long *rmap;
unsigned long *dirty_bitmap;
int user_alloc; /* user allocated memory */
+ unsigned long userspace_addr;
};
struct kvm {
@@ -652,6 +653,7 @@ int kvm_mmu_unprotect_page_virt(struct kvm_vcpu *vcpu,
gva_t gva);
void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
int kvm_mmu_load(struct kvm_vcpu *vcpu);
void kvm_mmu_unload(struct kvm_vcpu *vcpu);
+int kvm_mmu_unpin(struct kvm *kvm, gfn_t gfn);
int kvm_emulate_hypercall(struct kvm_vcpu *vcpu);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index a0f8366..74105d1 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -774,6 +774,7 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
unsigned long pages_num;
new.user_alloc = 1;
+ new.userspace_addr = mem->userspace_addr;
down_read(¤t->mm->mmap_sem);
pages_num = get_user_pages(current, current->mm,
@@ -1049,12 +1050,36 @@ struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm,
gfn_t gfn)
struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
{
struct kvm_memory_slot *slot;
+ struct page *page;
+ uint64_t slot_index;
gfn = unalias_gfn(kvm, gfn);
slot = __gfn_to_memslot(kvm, gfn);
if (!slot)
return NULL;
- return slot->phys_mem[gfn - slot->base_gfn];
+
+ slot_index = gfn - slot->base_gfn;
+ page = slot->phys_mem[slot_index];
+ if (unlikely(page == NULL)) {
+ unsigned long pages_num;
+
+ down_read(¤t->mm->mmap_sem);
+
+ pages_num = get_user_pages(current, current->mm,
+ slot->userspace_addr +
+ (slot_index << PAGE_SHIFT),
+ 1, 1, 0, &slot->phys_mem[slot_index],
+ NULL);
+
+ up_read(¤t->mm->mmap_sem);
+
+ if (pages_num != 1)
+ page = NULL;
+ else
+ page = slot->phys_mem[slot_index];
+ }
+
+ return page;
}
EXPORT_SYMBOL_GPL(gfn_to_page);
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index f52604a..1820816 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -820,6 +821,33 @@ static void mmu_unshadow(struct kvm *kvm, gfn_t gfn)
}
}
+int kvm_mmu_unpin(struct kvm *kvm, gfn_t gfn)
+{
+ struct kvm_memory_slot *slot;
+ struct page *page;
+
+ /* FIXME for each active vcpu */
+
+ gfn = unalias_gfn(kvm, gfn);
+ slot = gfn_to_memslot(kvm, gfn);
+ if (!gfn)
+ return -EINVAL;
+
+ /* FIXME: do we need to hold a lock here? */
+
+ /* Remove page from shadow MMU and unpin page */
+ mmu_unshadow(kvm, gfn);
+ page = slot->phys_mem[gfn - slot->base_gfn];
+ if (page) {
+ if (!PageReserved(page))
+ SetPageDirty(page);
+ page_cache_release(page);
+ slot->phys_mem[gfn - slot->base_gfn] = NULL;
+ }
+
+ return 0;
+}
+
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));
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] PV network performance comparison
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 when that is available. Jim Tests were run with Netperf-2.4.3, TCP Socket buffers were 256k. All of the tests were run with netserver in the guest, netperf in the host/dom0. No bridge was used. Hardware: IBM HS21 blade Dual Xeon w/HT @ 1.6GHz, 4GB The host/Dom0 configuration: kvm.*: Host is 32 bit Ubuntu 7.04 server running Dor's 2.6.22-rc3 kernel. xen.*: Dom0 is 32 bit Ubuntu 7.04 server running the 2.6.18 kernel from xen3.1 The guest configurations: All guests/domUs are 512MB, 1 CPU kvm.rtl: (KVM with emulated RTL8029) Fedora 7 32 bit guest Standard 2.6.21-1.3194.fc7 kernel kvm.pv: (KVM w/Dor's paravirt drivers) Fedora 7 32 bit guest running Dor's 2.6.22-rc3 kernel. xen.pv: (Xen paravirt) Ubuntu 7.04 server w/2.6.18-xen kernel xen.um: (Xen HVM with unmodified drivers) Ubuntu 7.04 server w/2.6.18-xen kernel, unmodified drivers compiled from xen3.1 kvm.lo: (Host loopback) TCP REQUEST/RESPONSE (Trans. Rate per sec) size kvm.rtl kvm.pvxen.pvxen.umkvm.lo 1 2191.47 9533.74 18052.37 13593.58 42400.73 642184.30 9518.13 17979.93 13557.98 42260.53 128 2177.52 9482.45 17940.08 13588.54 40983.90 256 2160.49 9465.97 17788.21 13492.42 41170.45 512 2130.99 9403.33 17655.11 13489.64 40765.26 1024 2074.85 9204.90 17293.06 13572.01 39437.78 2048 416.18 4750.41 12907.57 11571.07 37252.42 4096 265.22 3691.90 10990.67 9943.64 31905.03 8192 116.80 1892.25 8439.83 6604.64 24397.95 16384 92.06 1004.58 4535.86 3924.68 17460.30 TCP STREAM (Throughput 10^6bits/sec) sizekvm.rtl kvm.pv xen.pv xen.um kvm.lo 204833.06 507.21 555.94 1442.38 5409.73 409633.16 526.75 848.26 2359.42 6152.48 819233.13 527.99 997.69 2418.87 7267.73 1638433.08 525.95 1107.64 2379.50 8434.29 3276833.13 525.38 1199.08 2375.81 8857.09 6553633.20 523.39 1255.33 2473.92 9248.35 13107233.11 520.87 1292.54 2605.49 8559.21 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vcpu_ioctl v1
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 depends on it. You're right, the include needs to stay in. I should've seen that. I'll doublecheck next time I remove an #include. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vcpu_ioctl v1
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 static, and thus part of the kernel's global namespace in case kvm is built-in. As far as I know, modules are expected to prefix any symbol they use with their module name. I am sorry for the emotional part of it, I tend to stick to old names too once I got used to them. In case you decide you want kvm_vcpu_load/put again, let me know so that I can supply a patch on top of git that renames it. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vcpu_ioctl v1
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 > === > --- kvm.orig/drivers/kvm/kvm_main.c 2007-10-11 15:41:33.0 +0200 > +++ kvm/drivers/kvm/kvm_main.c2007-10-11 19:03:18.0 +0200 > @@ -28,7 +28,6 @@ > #include > #include > #include > -#include > #include > #include > #include > 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 depends on it. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vcpu_ioctl v1
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_SIGNAL_MASK, KVM_GET/SET_FPU > Note that some PPC chips don't have an FPU, so we might need an #ifdef > around KVM_GET/SET_FPU one day. > > x86 specific ioctls are: > KVM_GET/SET_LAPIC, KVM_SET_CPUID, KVM_GET/SET_MSRS > > An interresting aspect is vcpu_load/vcpu_put. We now have a common > kvm_vcpu_load/put which does the preemption stuff, and an architecture > specific kvm_arch_vcpu_load/put. In the x86 case, this one calls the > vmx/svm function defined in kvm_x86_ops. > 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. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] RFC/patch portability: split kvm_vcpu_ioctl v1
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 that some PPC chips don't have an FPU, so we might need an #ifdef
around KVM_GET/SET_FPU one day.
x86 specific ioctls are:
KVM_GET/SET_LAPIC, KVM_SET_CPUID, KVM_GET/SET_MSRS
An interresting aspect is vcpu_load/vcpu_put. We now have a common
kvm_vcpu_load/put which does the preemption stuff, and an architecture
specific kvm_arch_vcpu_load/put. In the x86 case, this one calls the
vmx/svm function defined in kvm_x86_ops.
signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
reviewed-by: Christian Borntraeger <[EMAIL PROTECTED]>
reviewed-by: Christian Ehrhardt <[EMAIL PROTECTED]>
---
Index: kvm/drivers/kvm/kvm.h
===
--- kvm.orig/drivers/kvm/kvm.h 2007-10-11 15:41:33.0 +0200
+++ kvm/drivers/kvm/kvm.h 2007-10-11 17:08:26.0 +0200
@@ -537,6 +537,10 @@
int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id);
void kvm_vcpu_uninit(struct kvm_vcpu *vcpu);
+void kvm_vcpu_load(struct kvm_vcpu *vcpu);
+void kvm_vcpu_put(struct kvm_vcpu *vcpu);
+
+
int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
struct module *module);
void kvm_exit_x86(void);
@@ -655,6 +659,11 @@
long kvm_arch_dev_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg);
+long kvm_arch_vcpu_ioctl(struct file *filp,
+unsigned int ioctl, unsigned long arg);
+void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
+void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu);
+
__init void kvm_arch_init(void);
static inline int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva,
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-10-11 15:41:33.0 +0200
+++ kvm/drivers/kvm/kvm_main.c 2007-10-11 19:03:18.0 +0200
@@ -28,7 +28,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -90,8 +89,6 @@
static struct dentry *debugfs_dir;
-#define MAX_IO_MSRS 256
-
#define CR0_RESERVED_BITS \
(~(unsigned long)(X86_CR0_PE | X86_CR0_MP | X86_CR0_EM | X86_CR0_TS \
| X86_CR0_ET | X86_CR0_NE | X86_CR0_WP | X86_CR0_AM \
@@ -177,23 +174,23 @@
EXPORT_SYMBOL_GPL(kvm_put_guest_fpu);
/*
- * Switches to specified vcpu, until a matching vcpu_put()
+ * Switches to specified vcpu, until a matching kvm_vcpu_put()
*/
-static void vcpu_load(struct kvm_vcpu *vcpu)
+void kvm_vcpu_load(struct kvm_vcpu *vcpu)
{
int cpu;
mutex_lock(&vcpu->mutex);
cpu = get_cpu();
preempt_notifier_register(&vcpu->preempt_notifier);
- kvm_x86_ops->vcpu_load(vcpu, cpu);
+ kvm_arch_vcpu_load(vcpu, cpu);
put_cpu();
}
-static void vcpu_put(struct kvm_vcpu *vcpu)
+void kvm_vcpu_put(struct kvm_vcpu *vcpu)
{
preempt_disable();
- kvm_x86_ops->vcpu_put(vcpu);
+ kvm_arch_vcpu_put(vcpu);
preempt_notifier_unregister(&vcpu->preempt_notifier);
preempt_enable();
mutex_unlock(&vcpu->mutex);
@@ -390,9 +387,9 @@
static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
{
- vcpu_load(vcpu);
+ kvm_vcpu_load(vcpu);
kvm_mmu_unload(vcpu);
- vcpu_put(vcpu);
+ kvm_vcpu_put(vcpu);
}
static void kvm_free_vcpus(struct kvm *kvm)
@@ -1566,9 +1563,9 @@
&& vcpu->mp_state != VCPU_MP_STATE_RUNNABLE
&& vcpu->mp_state != VCPU_MP_STATE_SIPI_RECEIVED) {
set_current_state(TASK_INTERRUPTIBLE);
- vcpu_put(vcpu);
+ kvm_vcpu_put(vcpu);
schedule();
- vcpu_load(vcpu);
+ kvm_vcpu_load(vcpu);
}
__set_current_state(TASK_RUNNING);
@@ -1765,7 +1762,7 @@
/*
* Reads an msr value (of 'msr_index') into 'pdata'.
* Returns 0 on success, non-0 otherwise.
- * Assumes vcpu_load() was already called.
+ * Assumes kvm_vcpu_load() was already called.
*/
int kvm_get_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 *pdata)
{
@@ -1837,7 +1834,7 @@
/*
* Writes msr value into into the appropriate "register".
* Returns 0 on success, non-0 otherwise.
- * Assumes vcpu_load() was already called.
+ * Assumes kvm_vcpu_load() was already called.
*/
int kvm_set_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 data)
{
@@ -2243,11 +2240,11 @@
int r;
sigset_t sigsaved;
- vcpu_load(vcpu);
+ kvm_vcpu_load(vcpu);
if (unlikely(vcpu->mp_state == VCPU_MP_STATE_UNINITIALIZED)) {
kvm_vcpu_block(vcpu);
- vcpu_put(vcpu);
+ kvm_
Re: [kvm-devel] soft lockup after stop/cont
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". Is that expected behavior? > >> We have the same behavior on s390 when running in a virtual > >> environment. The issue is, that the guest physical cpu may be > >> scheduled away while a timer runs down. I don't think there's anything > >> kvm could do better regerding the soft lockup code. Soft lockup is > >> just broken for virtualized environments and needs to be fixed. For > >> the time being, just disable it in kconfig. > >> > > This is a well known issue, but we can fix by syncing TSC with PIT etc. > > But doing this we need to froze guest TSC when a VP is descheduled. > > > > We enable this in Xen but feel it is too complicated so never wanna > > to do same thing in KVM per previous discussion. There are some > > side effect of course due to this. > > > > In Xen some time you will see PV domain soft lockup, but never in > > hardware HVM :-) Hopefully Linux will have pv timer soon. > Yes, virtual timers will be the right fix for it. I believe Jan has a > patch for that. Am I mistaken Jan? [adding Jan to CC:] Well, we have an instruction for that ;- (but that's not the whole story). The idea is simply to make sched_clock using a virtual timer, so softlockup does only account time the guest was scheduled. Currently we have softlockup disabled on s390 too, since there are some open issues with CFS and the virtual sched_clock. -- Jan - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Working on an entry-level project
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 reveals the problem? Related to that, what is the status of VMGL's (http://www.cs.toronto.edu/~andreslc/xen-gl/) integration with KVM or QEMU? Has anyone tried it? I've found some pages that refer to QEMU and VMGL but nothing definitive. Cam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Guest Time Question
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 virtual machine would be like another hardware baseline to verify. So we will have to do that to test the time correctness. What to do? Sending time stamped broadcast or multicast messages may well do the trick, I have yet to look on how the network stack or the guest and host work together in paravirtualization with KVM. Also I would not be sure what a 0.1% shift would be. From what do you mean the percentage? Or is that a typo and you would mean 0.1 ms ? Best regards, Kay Hayen > > So in FAQ and Wiki I didn't find how to make the guest use > > host time. Is that > > possible at all? For VMWare it is said that clock=pit would > > help, but that > > seemed to be no change. > > > > Can you please point me to what to do? > > > > Best regards, > > Kay Hayen > > If you can get latest KVM up + clock=pit, I bet you will get a much much > accurate guest time. If you still see > 0.1% shift, please file a bug. > thx,eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [GFXBOOT] [PATCH] When switching to real-mode, pass SS in a GP register
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 able to find anything definitive in my manuals but I didn't look very hard. I figured that erring on the safe side is better anyway. > Anyway, ss is already saved, so no need for an extra register. Here is > my version (tested and works on my machine): > This patch works for me under KVM. Thanks! Regards, Anthony Liguori > --- bincode.asm (revision 650) > +++ bincode.asm (working copy) > @@ -15546,7 +15546,11 @@ > mov ax,pm_seg.prog_d16 > mov ds,ax > > - mov eax,ss > + ; needed for KVM: > + ; ss:rpl must equal cs:rpl in PM for VT. We can't rely on ss > + ; maintaining its value after the transition. > + > + movzx eax,word [rm_seg.ss] > and esp,0h > shl eax,4 > add esp,eax > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] build error
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: [kvm-devel] build error
>
>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 something.
>
>The .c file which is missing is generated by the following lines:
>
>> cat > $TMPC <> int main(void) {}
>> EOF
>>
>
>I hate bash.
>
>
>--
>error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] build error
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 something.
The .c file which is missing is generated by the following lines:
> cat > $TMPC < int main(void) {}
> EOF
>
I hate bash.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] build error
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/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 error happens since yesterday.Before the machine has no problem to > build KVM. It should be a new regression. > > Thanks > Yunfeng > >> What is the output of the top-level ./configure? >> >> Note you need gcc 3.x, on Red Hat systems the package is called >> compat-gcc-32 or compat-gcc-34. >> >> -- >> error compiling committee.c: too many arguments to function > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > -- [EMAIL PROTECTED] - "Given enough eyeballs, all bugs are shallow" E. S. Raymond signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] build error
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 error happens since yesterday.Before the machine has no problem to build KVM. It should be a new regression. Thanks Yunfeng >> > >What is the output of the top-level ./configure? > >Note you need gcc 3.x, on Red Hat systems the package is called >compat-gcc-32 or compat-gcc-34. > >-- >error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/2] [FIXED] enable user makefile for cross compile
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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] build error
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 > > make[1]: *** No rule to make target `config-host.mak'. Stop. > > make[1]: Leaving directory > `/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071010190122210/kvm-userspace/qemu' > > make: *** [qemu] Error 2 > > . > > If run ./qemu/configure, it turns: > > [EMAIL PROTECTED] qemu]# ./configure > > ./configure: line 415: /tmp/qemu-conf-28011-8352-8345.c: No such file > or directory > > ERROR: "gcc" either does not exist or does not work > > How can I resolve this issue? > > I am using RHEL5 x86_64, gcc version 4.1.1 > What is the output of the top-level ./configure? Note you need gcc 3.x, on Red Hat systems the package is called compat-gcc-32 or compat-gcc-34. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH/RFC] Per-architecture hypercall definitions
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 Liguori
> [PATCH/RFC] Per-architecture hypercall definitions
>
> 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.
>
> Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
>
> Index: kvm/include/asm-x86/kvm_para.h
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ kvm/include/asm-x86/kvm_para.h2007-10-11 15:41:24.0 +0200
> @@ -0,0 +1,105 @@
> +#ifndef __X86_KVM_PARA_H
> +#define __X86_KVM_PARA_H
> +
> +/* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx. It
> + * should be used to determine that a VM is running under KVM.
> + */
> +#define KVM_CPUID_SIGNATURE 0x4000
> +
> +/* This CPUID returns a feature bitmap in eax. Before enabling a particular
> + * paravirtualization, the appropriate feature bit should be checked.
> + */
> +#define KVM_CPUID_FEATURES 0x4001
> +
> +#ifdef __KERNEL__
> +#include
> +
> +/* This instruction is vmcall. On non-VT architectures, it will generate a
> + * trap that we will then rewrite to the appropriate instruction.
> + */
> +#define KVM_HYPERCALL ".byte 0x0f,0x01,0xc1"
> +
> +/* For KVM hypercalls, a three-byte sequence of either the vmrun or the
> vmmrun
> + * instruction. The hypervisor may replace it with something else but only
> the
> + * instructions are guaranteed to be supported.
> + *
> + * Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively.
> + * The hypercall number should be placed in rax and the return value will be
> + * placed in rax. No other registers will be clobbered unless explicited
> + * noted by the particular hypercall.
> + */
> +
> +static inline long kvm_hypercall0(unsigned int nr)
> +{
> + long ret;
> + asm volatile(KVM_HYPERCALL
> + : "=a"(ret)
> + : "a"(nr));
> + return ret;
> +}
> +
> +static inline long kvm_hypercall1(unsigned int nr, unsigned long p1)
> +{
> + long ret;
> + asm volatile(KVM_HYPERCALL
> + : "=a"(ret)
> + : "a"(nr), "b"(p1));
> + return ret;
> +}
> +
> +static inline long kvm_hypercall2(unsigned int nr, unsigned long p1,
> + unsigned long p2)
> +{
> + long ret;
> + asm volatile(KVM_HYPERCALL
> + : "=a"(ret)
> + : "a"(nr), "b"(p1), "c"(p2));
> + return ret;
> +}
> +
> +static inline long kvm_hypercall3(unsigned int nr, unsigned long p1,
> + unsigned long p2, unsigned long p3)
> +{
> + long ret;
> + asm volatile(KVM_HYPERCALL
> + : "=a"(ret)
> + : "a"(nr), "b"(p1), "c"(p2), "d"(p3));
> + return ret;
> +}
> +
> +static inline long kvm_hypercall4(unsigned int nr, unsigned long p1,
> + unsigned long p2, unsigned long p3,
> + unsigned long p4)
> +{
> + long ret;
> + asm volatile(KVM_HYPERCALL
> + : "=a"(ret)
> + : "a"(nr), "b"(p1), "c"(p2), "d"(p3), "S"(p4));
> + return ret;
> +}
> +
> +static inline int kvm_para_available(void)
> +{
> + unsigned int eax, ebx, ecx, edx;
> + char signature[13];
> +
> + cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
> + memcpy(signature + 0, &ebx, 4);
> + memcpy(signature + 4, &ecx, 4);
> + memcpy(signature + 8, &edx, 4);
> + signature[12] = 0;
> +
> + if (strcmp(signature, "KVMKVMKVM") == 0)
> + return 1;
> +
> + return 0;
> +}
> +
> +static inline unsigned int kvm_arch_para_features(void)
> +{
> + return cpuid_eax(KVM_CPUID_FEATURES);
> +}
> +
> +#endif
> +
> +#endif
> Index: kvm/include/linux/kvm_para.h
> ===
> --- kvm.orig/include/linux/kvm_para.h 2007-10-11 13:28:46.0 +0200
> +++ kvm/include/linux/kvm_para.h 2007-10-11 15:41:53.0 +0200
> @@ -1,110 +1,29 @@
> #ifndef __LINUX_KVM_PARA_H
> #define __LINUX_KVM_PARA_H
>
> -/* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx. It
> - * should be used to determine that a VM is running under KVM.
> +/*
> + * This header file provides a method for making a hypercall to the host
> + * Architectures should define:
> + * - kvm_hypercall0, kvm_hypercall1...
> + * - kvm_arch_para_features
> + * - kvm_para_available
> */
> -#define KVM_CPUID_SIGNATURE 0x4000
> -
> -/* This CPUID returns a feature bitmap in eax. Before enabling a particular
> - * para
Re: [kvm-devel] [PATCH/RFC] Per-architecture hypercall definitions
> > +/* 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 think:
>
> kvm_hypercall0(KVM_HYPERCALL_FOO);
>
> Is a lot more understandable than:
>
> kvm_hypercall(0, KVM_HYPERCALL_FOO);
>
> It's much harder to guess with the later what the significance of the
> first parameter is.
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?
[PATCH/RFC] Per-architecture hypercall definitions
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.
Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
Index: kvm/include/asm-x86/kvm_para.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ kvm/include/asm-x86/kvm_para.h 2007-10-11 15:41:24.0 +0200
@@ -0,0 +1,105 @@
+#ifndef __X86_KVM_PARA_H
+#define __X86_KVM_PARA_H
+
+/* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx. It
+ * should be used to determine that a VM is running under KVM.
+ */
+#define KVM_CPUID_SIGNATURE0x4000
+
+/* This CPUID returns a feature bitmap in eax. Before enabling a particular
+ * paravirtualization, the appropriate feature bit should be checked.
+ */
+#define KVM_CPUID_FEATURES 0x4001
+
+#ifdef __KERNEL__
+#include
+
+/* This instruction is vmcall. On non-VT architectures, it will generate a
+ * trap that we will then rewrite to the appropriate instruction.
+ */
+#define KVM_HYPERCALL ".byte 0x0f,0x01,0xc1"
+
+/* For KVM hypercalls, a three-byte sequence of either the vmrun or the vmmrun
+ * instruction. The hypervisor may replace it with something else but only the
+ * instructions are guaranteed to be supported.
+ *
+ * Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively.
+ * The hypercall number should be placed in rax and the return value will be
+ * placed in rax. No other registers will be clobbered unless explicited
+ * noted by the particular hypercall.
+ */
+
+static inline long kvm_hypercall0(unsigned int nr)
+{
+ long ret;
+ asm volatile(KVM_HYPERCALL
+: "=a"(ret)
+: "a"(nr));
+ return ret;
+}
+
+static inline long kvm_hypercall1(unsigned int nr, unsigned long p1)
+{
+ long ret;
+ asm volatile(KVM_HYPERCALL
+: "=a"(ret)
+: "a"(nr), "b"(p1));
+ return ret;
+}
+
+static inline long kvm_hypercall2(unsigned int nr, unsigned long p1,
+ unsigned long p2)
+{
+ long ret;
+ asm volatile(KVM_HYPERCALL
+: "=a"(ret)
+: "a"(nr), "b"(p1), "c"(p2));
+ return ret;
+}
+
+static inline long kvm_hypercall3(unsigned int nr, unsigned long p1,
+ unsigned long p2, unsigned long p3)
+{
+ long ret;
+ asm volatile(KVM_HYPERCALL
+: "=a"(ret)
+: "a"(nr), "b"(p1), "c"(p2), "d"(p3));
+ return ret;
+}
+
+static inline long kvm_hypercall4(unsigned int nr, unsigned long p1,
+ unsigned long p2, unsigned long p3,
+ unsigned long p4)
+{
+ long ret;
+ asm volatile(KVM_HYPERCALL
+: "=a"(ret)
+: "a"(nr), "b"(p1), "c"(p2), "d"(p3), "S"(p4));
+ return ret;
+}
+
+static inline int kvm_para_available(void)
+{
+ unsigned int eax, ebx, ecx, edx;
+ char signature[13];
+
+ cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
+ memcpy(signature + 0, &ebx, 4);
+ memcpy(signature + 4, &ecx, 4);
+ memcpy(signature + 8, &edx, 4);
+ signature[12] = 0;
+
+ if (strcmp(signature, "KVMKVMKVM") == 0)
+ return 1;
+
+ return 0;
+}
+
+static inline unsigned int kvm_arch_para_features(void)
+{
+ return cpuid_eax(KVM_CPUID_FEATURES);
+}
+
+#endif
+
+#endif
Index: kvm/include/linux/kvm_para.h
===
--- kvm.orig/include/linux/kvm_para.h 2007-10-11 13:28:46.0 +0200
+++ kvm/include/linux/kvm_para.h2007-10-11 15:41:53.0 +0200
@@ -1,110 +1,29 @@
#ifndef __LINUX_KVM_PARA_H
#define __LINUX_KVM_PARA_H
-/* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx. It
- * should be used to determine that a VM is running under KVM.
+/*
+ * This header file provides a method for making a hypercall to the host
+ * Architectures sho
Re: [kvm-devel] kvm_rmap_desc: Can't free all objects
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_module_exit+0x23/0x37 >> [] :kvm:kvm_exit+0x26/0x31 >> [] sys_delete_module+0x1b4/0x1e5 >> [] __up_write+0x14/0x108 >> [] sys_munmap+0x4b/0x58 >> [] system_call+0x7e/0x83 >> >> > > I saw this yesterday and an debugging it now... > > It's caused by the mmu not handling permissions changing on a pde correctly. > > This is now fixed. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Hacking QEMU/KVM to use unused graphics adapters
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 >>> month. NIC pass through works but I'm not sure about the features >>> required from VGA pass through. Dor. >>> >> Perhaps if we use host IOMMU we don't need pv DMA ? >> > > Indeed, an IOMMU can provide the 1-1 mapping Dor mentioned above (or > you can have both PV DMA and an IOMMU). > > >> How do you say to host to not manage a PCI devices and let the guest >> managing it ? >> > > If the host driver is modular, it might be enough to just not load (or > unload) it. > > Cheers, > Muli > Thank you for your responses. I was curious, Dor, where could I take a look at this code? I checked both sets of recent git logs and nothing popped out at me as being related. Is it still out-of-tree? Thanks again, - Tony - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH/RFC] Per-architecture hypercall definitions
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 insertions(+), 99 deletions(-)
>
> Index: kvm/include/asm-x86/kvm_para.h
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ kvm/include/asm-x86/kvm_para.h2007-10-11 14:05:25.0 +0200
> @@ -0,0 +1,108 @@
> +#ifndef __X86_KVM_PARA_H
> +#define __X86_KVM_PARA_H
> +
> +/* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx. It
> + * should be used to determine that a VM is running under KVM.
> + */
> +#define KVM_CPUID_SIGNATURE 0x4000
> +
> +/* This CPUID returns a feature bitmap in eax. Before enabling a particular
> + * paravirtualization, the appropriate feature bit should be checked.
> + */
> +#define KVM_CPUID_FEATURES 0x4001
> +
> +/* Return values for hypercalls */
> +#define KVM_ENOSYS 1000
>
errno's can probably be in common code, right?
>
> +#define kvm_hypercall(nr_params, args...)\
> +({ \
> + long __ret; \
> + \
> + __ret = kvm_hypercall##nr_params(args); \
> + \
> + __ret; \
> +})
>
Why store results to a variable? It would also probably be better to
use the C99 variadic macro format which would be:
#define kvm_hypercall(nr_params, ...) kvm_hypercall##nr_params(__VA_ARGS__)
I originally had one of these in my paravirt_ops implementation but
quickly found that the code it produced was pretty ugly. I think:
kvm_hypercall0(KVM_HYPERCALL_FOO);
Is a lot more understandable than:
kvm_hypercall(0, KVM_HYPERCALL_FOO);
It's much harder to guess with the later what the significance of the
first parameter is.
Regards,
Anthony Liguori
> +#endif
> #endif
> Index: kvm/include/asm-s390/kvm_para.h
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ kvm/include/asm-s390/kvm_para.h 2007-10-11 14:09:12.0 +0200
> @@ -0,0 +1,146 @@
> +#ifndef __S390_KVM_PARA_H
> +#define __S390_KVM_PARA_H
> +
> +/*
> + * This is subject to change:
> + *
> + * Hypercalls for KVM on s390. The calling convention is similar to the
> + * s390 ABI, so we use R2-R6 for parameters 1-5. In addition we use R1
> + * as hypercall number and R7 as parameter 6. The return value is
> + * written to R2. We use the diagnose instruction as hypercall. To avoid
> + * conflicts with existing diagnoses for LPAR and z/VM, we do not use
> + * the instruction encoded number, but specify the number in R1 and
> + * use 0xBB as KVM diagnose number.
> + *
> + * Copyright 2007, IBM Corp.
> + * Author(s) Christian Borntraeger <[EMAIL PROTECTED]>
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.
> + */
> +
> +static inline long kvm_hypercall0(unsigned long nr)
> +{
> + register unsigned long __nr asm("1") = nr;
> + register long __rc asm("2");
> +
> + asm volatile ("diag 2,4,0xBB\n"
> + : "=d" (__rc) : "d" (__nr): "memory", "cc");
> + return __rc;
> +}
> +
> +static inline long kvm_hypercall1(unsigned long nr, unsigned long p1)
> +{
> + register unsigned long __nr asm("1") = nr;
> + register unsigned long __p1 asm("2") = p1;
> + register long __rc asm("2");
> +
> + asm volatile ("diag 2,4,0xBB\n"
> + : "=d" (__rc) : "d" (__nr), "0" (__p1) : "memory", "cc");
> + return __rc;
> +}
> +
> +static inline long kvm_hypercall2(unsigned long nr, unsigned long p1,
> +unsigned long p2)
> +{
> + register unsigned long __nr asm("1") = nr;
> + register unsigned long __p1 asm("2") = p1;
> + register unsigned long __p2 asm("3") = p2;
> + register long __rc asm("2");
> +
> + asm volatile ("diag 2,4,0xBB\n"
> + : "=d" (__rc) : "d" (__nr), "0" (__p1), "d" (__p2)
> + : "memory", "cc");
> + return __rc;
> +}
> +
> +static inline long kvm_hypercall3(unsigned long nr, unsigned long p1,
> +unsigned long p2, unsigned long p3)
> +{
> + register unsigned long __nr asm("1") = nr;
> + register unsigned long __p1 asm("2") = p1;
> + register unsigned long __p2 asm("3") = p2;
> + register unsigned long __p3 asm("4") = p3;
> + register long __rc asm("2");
> +
> + asm volatile ("diag 2,4,0xBB\n"
> + : "=d" (__rc) : "d" (__nr), "0" (__p1), "d" (__p2),
> + "d" (__p3) : "memory", "cc");
> + return __rc;
> +}
> +
> +
> +static inline long kvm_
Re: [kvm-devel] [Patch] [0/3] Patches to support new architectures.
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 >>> third patch, we add a sub field struct kvm_arch_ops for arch-specific >>> ops. That is, different CPU archs can define its arch-specific >>> ops for its special need. IMO, we should treat x86, IA64, ppc etc as >>> different archtiectures, other than see vmx, svm as different archs. >>> svm and vmx should be two different virtualization approaches for >>> x86 arch from the point view of platforms. >>> >>> >> ia64, ppc, and s390 don't need to select an implementation at runtime >> (since each have just one instruction set) so they don't need function >> pointers. Instead we should use linkage (different functions for each >> arch, but with the same names). Kbuild will select the right files to >> compile depending on arch. >> > > For x86 side, how to handle the co-existence of vmx and svm ? For > example, in a release linux kernel which supports KVM, how to know it > will be installed to Intel or AMD platforms ? If we determin it in > advance, we have to compile them all in at one time, but it maybe > difficult for current > kvm code to implement. > 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 are very different as kvm_x86_ops is very low level and x86 specific. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch] [0/3] Patches to support new architectures.
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_arch_ops for arch-specific >> ops. That is, different CPU archs can define its arch-specific >> ops for its special need. IMO, we should treat x86, IA64, ppc etc as >> different archtiectures, other than see vmx, svm as different archs. >> svm and vmx should be two different virtualization approaches for >> x86 arch from the point view of platforms. >> > > ia64, ppc, and s390 don't need to select an implementation at runtime > (since each have just one instruction set) so they don't need function > pointers. Instead we should use linkage (different functions for each > arch, but with the same names). Kbuild will select the right files to > compile depending on arch. For x86 side, how to handle the co-existence of vmx and svm ? For example, in a release linux kernel which supports KVM, how to know it will be installed to Intel or AMD platforms ? If we determin it in advance, we have to compile them all in at one time, but it maybe difficult for current kvm code to implement. >> 3. re-frame.patch. This patch is the main work to to support >> differnt architectures. it includes: (1). Split kvm_main.c to >> kvm_arch.c and new kvm_main.c. kvm_arch.c under x86 directory >> contains arch-specific code, and new kvm_main.c only holds >> interfaces with user space, and basic kvm infrastructure. Split >> some functions to make them arch-independent. (2) Add an include >> directory to hold head files, and split kvm.h to two parts. One is >> kvm_arch.h to deposit some arch-specfic structures, such as struct >> kvm_vcpu_arch, kvm_arch_ops etc, some arch-dependent macros and >> functions declares. (3) Add arch support for structure kvm_ops, and >> structure kvm_vcpu. (4) Make file change. >> > > This is all too big. Carsten's approach (one thing at a time) is > better since it allows easy review of what is happening. OK. If we have consistent ideas for ultimate layouts, it should be easy to do. Thank you for your comments. Xiantao - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH/RFC] Per-architecture hypercall definitions
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 (experimental, ABI not final, > and I still have to find out how to get an assigned diagnose number) > and x86. I already made the split using the common x86 architecture > folder that will hit 2.6.24-rc soon. > > Looks good. I'll commit (minus the s390 part) once the x86 merge is behind us. > One point for discussion: > > i386 only supports up to 4 parameters. On s390 I coded definitions for > up to 6 parameters. Are we going to limit kvm to 4 parameters? > I guess we can add more parameters if the need arises. We don't clobber registers so there's no issue with that. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kernel device reset support
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.
>
>
Doesn't this code imply that waiting for SIPI is supported?
> static void kvm_vcpu_block(struct kvm_vcpu *vcpu)
> {
> DECLARE_WAITQUEUE(wait, current);
>
> add_wait_queue(&vcpu->wq, &wait);
>
> /*
> * We will block until either an interrupt or a signal wakes us up
> */
> while (!kvm_cpu_has_interrupt(vcpu)
>&& !signal_pending(current)
>&& vcpu->mp_state != VCPU_MP_STATE_RUNNABLE
>&& vcpu->mp_state != VCPU_MP_STATE_SIPI_RECEIVED) {
(note waiting for SIPI here)
> set_current_state(TASK_INTERRUPTIBLE);
> vcpu_put(vcpu);
> schedule();
> vcpu_load(vcpu);
> }
>
> __set_current_state(TASK_RUNNING);
> remove_wait_queue(&vcpu->wq, &wait);
> }
>>> Yes, halt all APs and let BSP do reset ops in user level.
>>> Will post patch to Qemu to support SMP reboot some time later.
>>>
>>>
>>>
>> Wait, that's a big change. Need to think about this...
>>
>
> Like talked in previous, we either let BSP do this, or let an AP
> become BSP. Current Qemu doesn't support this.
>
>
>>> - if (vcpu->requests)
>>> + if (vcpu->requests) {
>>> if (test_and_clear_bit(KVM_TLB_FLUSH, &vcpu->requests))
>>> kvm_x86_ops->tlb_flush(vcpu);
>>> + if (test_and_clear_bit(KVM_FROZEN, &vcpu->requests)) {
>>> + local_irq_enable(); +
>>>
> preempt_enable();
>
>>> + r = -EINTR;
>>> + kvm_run->exit_reason = KVM_EXIT_FROZEN;
>>> + goto out;
>>> + }
>>> + }
>>>
>>>
>> Why not just call vcpu_reset() here, then call vcpu_halt() if
>> we're an AP?
>>
>
> Then you need to duplicate following code, which may bring extra issue
> such as GUEST_CR3 update (kvm_mmu_reload) which is done after
> this code but before vcpu->requests test. BTW, switch back to user level
> to retry is cleaner IMO.
>
> if (unlikely(vcpu->mp_state == VCPU_MP_STATE_UNINITIALIZED)) {
> if (irqchip_in_kernel(vcpu->kvm) && vcpu->apic)
> kvm_lapic_reset(vcpu);
> kvm_vcpu_block(vcpu);
> vcpu_put(vcpu);
> return -EAGAIN;
> }
>
>
You can put a goto to the top of the loop to redo the mmu reload. In
any case you need to do that because you don't want to execute the reset
code with interrupts and preemption disabled.
>>> + while (test_bit(KVM_FROZEN, &vcpu->requests))
>>> + schedule();
>>>
>>>
>> I don't think we need to wait here.
>>
>
> The VCPU may be executing in kernel still, which may modify kernel
> device state. E.g. A VCPU may be doing PIO emulating.
>
>
In that case we will wait when taking kvm->lock.
> If BSP reset the kernel devices earlier than the VCPU modify the device
> state,
> we are in trouble.
>
Right, so the logic is:
- send IPI to all vcpus to stop them running
- take the lock and reset all devices, srop the lock
- unblock vcpu 0
>
>>> + }
>>> + else {
>>> + vcpu->mp_state = VCPU_MP_STATE_RUNNABLE;
>>> + kvm_lapic_reset(vcpu);
>>> + }
>>> + }
>>> + /* Now only BSP is running... */
>>> + kvm_reset_devices(kvm);
>>>
>>>
>> But now you're reseting the devices while vcpu 0 may be
>> running. If in
>>
>
> No, VCPU0 (BSP) is current VCPU (though you don't have the current
> vcpu parameter explicitly) like mentioned in previous mail and
> as pre-requirement of user level change. Please refer my abswer above
> of this mail.
>
>
We can't rely on user space not to cause host kernel corruption.
>> the first stage you halt all vcpus, and then restart vcpu 0 after the
>> reset, you avoid the race.
>>
>>
>
> No race here. The code is executing in VCPU0 context.
>
>
It isn't guaranteed.
It's okay to rely on it for guest correctness (though undesirable), not
host correctness.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH/RFC] Per-architecture hypercall definitions
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 to find out how to get an assigned diagnose number)
and x86. I already made the split using the common x86 architecture
folder that will hit 2.6.24-rc soon.
One point for discussion:
i386 only supports up to 4 parameters. On s390 I coded definitions for
up to 6 parameters. Are we going to limit kvm to 4 parameters?
Besides the experimental state of the s390 ABI, the patch should be
mergable as soon as the x86 merge is finished.
Feedback is welcome.
Christian
---
include/asm-s390/kvm_para.h | 128
include/asm-x86/kvm_para.h | 110 +
include/linux/kvm_para.h| 112 --
3 files changed, 251 insertions(+), 99 deletions(-)
Index: kvm/include/asm-x86/kvm_para.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ kvm/include/asm-x86/kvm_para.h 2007-10-11 14:05:25.0 +0200
@@ -0,0 +1,108 @@
+#ifndef __X86_KVM_PARA_H
+#define __X86_KVM_PARA_H
+
+/* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx. It
+ * should be used to determine that a VM is running under KVM.
+ */
+#define KVM_CPUID_SIGNATURE0x4000
+
+/* This CPUID returns a feature bitmap in eax. Before enabling a particular
+ * paravirtualization, the appropriate feature bit should be checked.
+ */
+#define KVM_CPUID_FEATURES 0x4001
+
+/* Return values for hypercalls */
+#define KVM_ENOSYS 1000
+
+#ifdef __KERNEL__
+#include
+
+/* This instruction is vmcall. On non-VT architectures, it will generate a
+ * trap that we will then rewrite to the appropriate instruction.
+ */
+#define KVM_HYPERCALL ".byte 0x0f,0x01,0xc1"
+
+/* For KVM hypercalls, a three-byte sequence of either the vmrun or the vmmrun
+ * instruction. The hypervisor may replace it with something else but only the
+ * instructions are guaranteed to be supported.
+ *
+ * Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively.
+ * The hypercall number should be placed in rax and the return value will be
+ * placed in rax. No other registers will be clobbered unless explicited
+ * noted by the particular hypercall.
+ */
+
+static inline long kvm_hypercall0(unsigned int nr)
+{
+ long ret;
+ asm volatile(KVM_HYPERCALL
+: "=a"(ret)
+: "a"(nr));
+ return ret;
+}
+
+static inline long kvm_hypercall1(unsigned int nr, unsigned long p1)
+{
+ long ret;
+ asm volatile(KVM_HYPERCALL
+: "=a"(ret)
+: "a"(nr), "b"(p1));
+ return ret;
+}
+
+static inline long kvm_hypercall2(unsigned int nr, unsigned long p1,
+ unsigned long p2)
+{
+ long ret;
+ asm volatile(KVM_HYPERCALL
+: "=a"(ret)
+: "a"(nr), "b"(p1), "c"(p2));
+ return ret;
+}
+
+static inline long kvm_hypercall3(unsigned int nr, unsigned long p1,
+ unsigned long p2, unsigned long p3)
+{
+ long ret;
+ asm volatile(KVM_HYPERCALL
+: "=a"(ret)
+: "a"(nr), "b"(p1), "c"(p2), "d"(p3));
+ return ret;
+}
+
+static inline long kvm_hypercall4(unsigned int nr, unsigned long p1,
+ unsigned long p2, unsigned long p3,
+ unsigned long p4)
+{
+ long ret;
+ asm volatile(KVM_HYPERCALL
+: "=a"(ret)
+: "a"(nr), "b"(p1), "c"(p2), "d"(p3), "S"(p4));
+ return ret;
+}
+
+static inline int kvm_para_available(void)
+{
+ unsigned int eax, ebx, ecx, edx;
+ char signature[13];
+
+ cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
+ memcpy(signature + 0, &ebx, 4);
+ memcpy(signature + 4, &ecx, 4);
+ memcpy(signature + 8, &edx, 4);
+ signature[12] = 0;
+
+ if (strcmp(signature, "KVMKVMKVM") == 0)
+ return 1;
+
+ return 0;
+}
+
+static inline unsigned int kvm_arch_para_features(void)
+{
+ return cpuid_eax(KVM_CPUID_FEATURES);
+}
+
+#endif
+
+#endif
Index: kvm/include/linux/kvm_para.h
===
--- kvm.orig/include/linux/kvm_para.h 2007-10-11 13:28:46.0 +0200
+++ kvm/include/linux/kvm_para.h2007-10-11 14:06:47.0 +0200
@@ -1,110 +1,36 @@
#ifndef __LINUX_KVM_PARA_H
#define __LINUX_KVM_PARA_H
-/* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx. It
- * should be used to determine that a VM is running under KVM.
+/*
+ * This header f
Re: [kvm-devel] RFC/patch: a very trivial patch towards portability V3
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 stuff for now. Okay, will come up with the next function to split soon. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] More struct page cleanups
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 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Clean up MMU functions to take struct kvm when appropriate (v2)
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 take a struct kvm. This > makes things a bit more clear. > > The main thing that was confusing me was whether certain functions need to be > called on all VCPUs. > > Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] Remove memory size from linker script (v2)
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, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch] [0/3] Patches to support new architectures.
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 > ops. That is, different CPU archs can define its arch-specific > ops for its special need. IMO, we should treat x86, IA64, ppc etc as > different archtiectures, other than see vmx, svm as different archs. svm > and vmx should be two different virtualization approaches for x86 arch > from the point view of platforms. > ia64, ppc, and s390 don't need to select an implementation at runtime (since each have just one instruction set) so they don't need function pointers. Instead we should use linkage (different functions for each arch, but with the same names). Kbuild will select the right files to compile depending on arch. > 3. re-frame.patch. This patch is the main work to to support differnt > architectures. it includes: > (1). Split kvm_main.c to kvm_arch.c and new kvm_main.c. kvm_arch.c under > x86 directory contains arch-specific code, and new kvm_main.c only holds > interfaces with user space, and basic kvm infrastructure. Split some > functions to make them arch-independent. > (2) Add an include directory to hold head files, and split kvm.h to two > parts. One is kvm_arch.h to deposit some arch-specfic structures, such > as struct kvm_vcpu_arch, kvm_arch_ops etc, some arch-dependent macros > and functions declares. > (3) Add arch support for structure kvm_ops, and structure kvm_vcpu. > (4) Make file change. > This is all too big. Carsten's approach (one thing at a time) is better since it allows easy review of what is happening. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch: a very trivial patch towards portability V3
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_EXTENSIONS with > information about capabilities they support. Possible valus for the bit > masks are defined in drivers/kvm/kvm.h (KVM_ARCH_HAS_*), which rely on > KVM_CAP_* definitions in include/linux/kvm.h. > Function prototypes in drivers/kvm/kvm.h have been fixed: they have > argument names now. > > The new capability bitmap moves the patch out of the "very trivial" realm. I removed those hunks and applied. Send more, the approach is clearly right. Leave things which require changes (like the capability bitmap) to the end, there's more than enough stuff for now. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] soft lockup after stop/cont
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 virtual >> environment. The issue is, that the guest physical cpu may be >> scheduled away while a timer runs down. I don't think there's anything >> kvm could do better regerding the soft lockup code. Soft lockup is >> just broken for virtualized environments and needs to be fixed. For >> the time being, just disable it in kconfig. >> > This is a well known issue, but we can fix by syncing TSC with PIT etc. > But doing this we need to froze guest TSC when a VP is descheduled. > > We enable this in Xen but feel it is too complicated so never wanna > to do same thing in KVM per previous discussion. There are some > side effect of course due to this. > > In Xen some time you will see PV domain soft lockup, but never in > hardware HVM :-) Hopefully Linux will have pv timer soon. Yes, virtual timers will be the right fix for it. I believe Jan has a patch for that. Am I mistaken Jan? [adding Jan to CC:] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Hacking QEMU/KVM to use unused graphics adapters
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 works but I'm not sure about the features > > required from VGA pass through. Dor. > > Perhaps if we use host IOMMU we don't need pv DMA ? Indeed, an IOMMU can provide the 1-1 mapping Dor mentioned above (or you can have both PV DMA and an IOMMU). > How do you say to host to not manage a PCI devices and let the guest > managing it ? If the host driver is modular, it might be enough to just not load (or unload) it. Cheers, Muli -- SYSTOR 2007 --- 1st Annual Haifa Systems and Storage Conference 2007 http://www.haifa.il.ibm.com/Workshops/systor2007/ Virtualization workshop: Oct 29th, 2007 | Storage workshop: Oct 30th, 2007 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch] [0/3] Patches to support new architectures.
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. Could you also please > post the patches inline, so that we can reply and comment on the code? > Could you please try to split your patches into small reviewable Thanks. put them inline. What the first patch did is moving files, so don't put them inline and just put generated comments in. thanks, Xiantao > thanks, > Carsten > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. Download your FREE copy of Splunk now >> > http://get.splunk.com/ ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [Patch][1/3] Move files to final position in source structure.
>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/ioapic.c | 388 - drivers/kvm/irq.c| 99 -- drivers/kvm/irq.h| 165 --- drivers/kvm/kvm.h| 814 --- drivers/kvm/kvm_svm.h| 45 - drivers/kvm/lapic.c | 1056 -- drivers/kvm/mmu.c| 1619 - drivers/kvm/paging_tmpl.h| 545 --- drivers/kvm/segment_descriptor.h | 17 - drivers/kvm/svm.c| 1749 --- drivers/kvm/svm.h| 324 - drivers/kvm/vmx.c| 2591 -- drivers/kvm/vmx.h| 310 drivers/kvm/x86/Makefile | 13 + drivers/kvm/x86/i8259.c | 450 ++ drivers/kvm/x86/ioapic.c | 388 + drivers/kvm/x86/irq.c| 99 ++ drivers/kvm/x86/irq.h| 165 +++ drivers/kvm/x86/kvm.h| 814 +++ drivers/kvm/x86/kvm_arch.c |1 + drivers/kvm/x86/kvm_svm.h| 45 + drivers/kvm/x86/lapic.c | 1056 ++ drivers/kvm/x86/mmu.c| 1619 + drivers/kvm/x86/paging_tmpl.h| 545 +++ drivers/kvm/x86/segment_descriptor.h | 17 + drivers/kvm/x86/svm.c| 1749 +++ drivers/kvm/x86/svm.h| 324 + drivers/kvm/x86/vmx.c| 2591 ++ drivers/kvm/x86/vmx.h| 310 drivers/kvm/x86/x86_emulate.c| 1772 +++ drivers/kvm/x86/x86_emulate.h| 186 +++ drivers/kvm/x86_emulate.c| 1772 --- drivers/kvm/x86_emulate.h| 186 --- 34 files changed, 12144 insertions(+), 12130 deletions(-) delete mode 100644 drivers/kvm/i8259.c delete mode 100644 drivers/kvm/ioapic.c delete mode 100644 drivers/kvm/irq.c delete mode 100644 drivers/kvm/irq.h delete mode 100644 drivers/kvm/kvm.h delete mode 100644 drivers/kvm/kvm_svm.h delete mode 100644 drivers/kvm/lapic.c delete mode 100644 drivers/kvm/mmu.c delete mode 100644 drivers/kvm/paging_tmpl.h delete mode 100644 drivers/kvm/segment_descriptor.h delete mode 100644 drivers/kvm/svm.c delete mode 100644 drivers/kvm/svm.h delete mode 100644 drivers/kvm/vmx.c delete mode 100644 drivers/kvm/vmx.h create mode 100644 drivers/kvm/x86/Makefile create mode 100644 drivers/kvm/x86/i8259.c create mode 100644 drivers/kvm/x86/ioapic.c create mode 100644 drivers/kvm/x86/irq.c create mode 100644 drivers/kvm/x86/irq.h create mode 100644 drivers/kvm/x86/kvm.h create mode 100644 drivers/kvm/x86/kvm_arch.c create mode 100644 drivers/kvm/x86/kvm_svm.h create mode 100644 drivers/kvm/x86/lapic.c create mode 100644 drivers/kvm/x86/mmu.c create mode 100644 drivers/kvm/x86/paging_tmpl.h create mode 100644 drivers/kvm/x86/segment_descriptor.h create mode 100644 drivers/kvm/x86/svm.c create mode 100644 drivers/kvm/x86/svm.h create mode 100644 drivers/kvm/x86/vmx.c create mode 100644 drivers/kvm/x86/vmx.h create mode 100644 drivers/kvm/x86/x86_emulate.c create mode 100644 drivers/kvm/x86/x86_emulate.h delete mode 100644 drivers/kvm/x86_emulate.c delete mode 100644 drivers/kvm/x86_emulate.h - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch][2/3]
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/Kconfig | 19 +++--
drivers/kvm/Makefile | 14 ++--
drivers/kvm/kvm_main.c| 176
drivers/kvm/x86/Makefile |2 +-
drivers/kvm/x86/kvm.h |6 +-
drivers/kvm/x86/mmu.c |6 +-
drivers/kvm/x86/paging_tmpl.h |2 +-
drivers/kvm/x86/svm.c |2 +-
drivers/kvm/x86/vmx.c |2 +-
drivers/kvm/x86/x86_emulate.c |4 +-
10 files changed, 119 insertions(+), 114 deletions(-)
diff --git a/drivers/kvm/Kconfig b/drivers/kvm/Kconfig
index 8749fa4..fc3a4e4 100644
--- a/drivers/kvm/Kconfig
+++ b/drivers/kvm/Kconfig
@@ -3,7 +3,7 @@
#
menuconfig VIRTUALIZATION
bool "Virtualization"
- depends on X86
+ depends on X86 || IA64
default y
---help---
Say Y here to get to see options for using your Linux host to run
other
@@ -16,7 +16,7 @@ if VIRTUALIZATION
config KVM
tristate "Kernel-based Virtual Machine (KVM) support"
- depends on X86 && EXPERIMENTAL
+ depends on (X86 || IA64) && EXPERIMENTAL
select PREEMPT_NOTIFIERS
select ANON_INODES
---help---
@@ -33,18 +33,25 @@ config KVM
If unsure, say N.
-config KVM_INTEL
+config KVM_VMX
tristate "KVM for Intel processors support"
- depends on KVM
+ depends on KVM && X86
---help---
Provides support for KVM on Intel processors equipped with the VT
extensions.
-config KVM_AMD
+config KVM_SVM
tristate "KVM for AMD processors support"
- depends on KVM
+ depends on KVM && X86
---help---
Provides support for KVM on AMD processors equipped with the AMD-V
(SVM) extensions.
+config KVM_VTI
+ tristate "KVM for Intel Itanium processors support"
+ depends on KVM && IA64
+ ---help---
+ Provides support for KVM on Intel Itanium processors equipped with
the VT
+ extensions.
+
endif # VIRTUALIZATION
diff --git a/drivers/kvm/Makefile b/drivers/kvm/Makefile
index e5a8f4d..8051cf7 100644
--- a/drivers/kvm/Makefile
+++ b/drivers/kvm/Makefile
@@ -1,10 +1,8 @@
#
-# Makefile for Kernel-based Virtual Machine module
+# Makefile to build KVM modules
#
-
-kvm-objs := kvm_main.o mmu.o x86_emulate.o i8259.o irq.o lapic.o ioapic.o
-obj-$(CONFIG_KVM) += kvm.o
-kvm-intel-objs = vmx.o
-obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
-kvm-amd-objs = svm.o
-obj-$(CONFIG_KVM_AMD) += kvm-amd.o
+ifneq ($(CONFIG_KVM),)
+KVM_ARCH =$(shell uname -i | sed -e 's/.*86.*/x86/g')
+EXTRA_CFLAGS += -Idrivers/kvm/$(KVM_ARCH)
+obj-$(CONFIG_KVM) = $(KVM_ARCH)/
+endif
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index f39ac58..bb9f460 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -55,7 +55,7 @@ static LIST_HEAD(vm_list);
static cpumask_t cpus_hardware_enabled;
-struct kvm_x86_ops *kvm_x86_ops;
+struct kvm_ops *kvm_ops;
struct kmem_cache *kvm_vcpu_cache;
EXPORT_SYMBOL_GPL(kvm_vcpu_cache);
@@ -184,14 +184,14 @@ static void vcpu_load(struct kvm_vcpu *vcpu)
mutex_lock(&vcpu->mutex);
cpu = get_cpu();
preempt_notifier_register(&vcpu->preempt_notifier);
- kvm_x86_ops->vcpu_load(vcpu, cpu);
+ kvm_ops->vcpu_load(vcpu, cpu);
put_cpu();
}
static void vcpu_put(struct kvm_vcpu *vcpu)
{
preempt_disable();
- kvm_x86_ops->vcpu_put(vcpu);
+ kvm_ops->vcpu_put(vcpu);
preempt_notifier_unregister(&vcpu->preempt_notifier);
preempt_enable();
mutex_unlock(&vcpu->mutex);
@@ -384,7 +384,7 @@ static void kvm_free_vcpus(struct kvm *kvm)
kvm_unload_vcpu_mmu(kvm->vcpus[i]);
for (i = 0; i < KVM_MAX_VCPUS; ++i) {
if (kvm->vcpus[i]) {
- kvm_x86_ops->vcpu_free(kvm->vcpus[i]);
+ kvm_ops->vcpu_free(kvm->vcpus[i]);
kvm->vcpus[i] = NULL;
}
}
@@ -415,7 +415,7 @@ static int kvm_vm_release(struct inode *inode, struct file
*filp)
static void inject_gp(struct kvm_vcpu *vcpu)
{
- kvm_x86_ops->inject_gp(vcpu, 0);
+ kvm_ops->inject_gp(vcpu, 0);
}
/*
@@ -484,7 +484,7 @@ void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
inject_gp(vcpu);
return;
}
- kvm_x86_ops->get_cs_db_l_bits(vcpu, &cs_db, &cs_l);
+ kvm_ops->get_cs_db_l_bits(vcpu, &cs_db, &cs_l);
if (cs_l) {
printk(KERN_DEBUG "set_cr0: #GP, start paging "
"in
Re: [kvm-devel] soft lockup after stop/cont
[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 issue is, that the guest physical cpu may be > scheduled away while a timer runs down. I don't think there's anything > kvm could do better regerding the soft lockup code. Soft lockup is > just broken for virtualized environments and needs to be fixed. For > the time being, just disable it in kconfig. > This is a well known issue, but we can fix by syncing TSC with PIT etc. But doing this we need to froze guest TSC when a VP is descheduled. We enable this in Xen but feel it is too complicated so never wanna to do same thing in KVM per previous discussion. There are some side effect of course due to this. In Xen some time you will see PV domain soft lockup, but never in hardware HVM :-) Hopefully Linux will have pv timer soon. thx, eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch] [0/3] Patches to support new architectures.
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 the patches inline, so that we can reply and comment on the code? Could you please try to split your patches into small reviewable patches? thanks, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [Patch][1/3] Move files to its final postion in source structure
>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 Description: 0003-This-patch-is-the-main-work-to-to-support-differnt-a.patch.tar - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch: a very trivial patch towards portability V3
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/discussed from the power perspective before they are submitted.
Applying these patches now (I expect that Carsten will submit more) will reduce
the size of the patches that we eventually need integrate our architecture.
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
+49 7031/16-3385
[EMAIL PROTECTED]
[EMAIL PROTECTED]
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
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_EXTENSIONS with
> information about capabilities they support. Possible valus for the bit
> masks are defined in drivers/kvm/kvm.h (KVM_ARCH_HAS_*), which rely on
> KVM_CAP_* definitions in include/linux/kvm.h.
> Function prototypes in drivers/kvm/kvm.h have been fixed: they have
> argument names now.
>
> signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
> ---
> Index: kvm/drivers/kvm/kvm.h
> ===
> --- kvm.orig/drivers/kvm/kvm.h2007-10-10 12:42:21.0 +0200
> +++ kvm/drivers/kvm/kvm.h 2007-10-10 17:00:12.0 +0200
> @@ -64,6 +64,12 @@
>
> #define KVM_PIO_PAGE_OFFSET 1
>
> +#define KVM_ARCH_HAS_IRQCHIP (1ull << KVM_CAP_IRQCHIP)
> +#define KVM_ARCH_HAS_HLT (1ull << KVM_CAP_HLT)
> +#define KVM_ARCH_HAS_MMU_SHADOW_CACHE_CONTROL \
> +(1ull << KVM_CAP_MMU_SHADOW_CACHE_CONTROL)
> +#define KVM_ARCH_HAS_USER_MEMORY (1ull << KVM_CAP_USER_MEMORY)
> +
> /*
> * vcpu->requests bit members
> */
> @@ -653,6 +659,10 @@
>
> int kvm_fix_hypercall(struct kvm_vcpu *vcpu);
>
> +long kvm_arch_dev_ioctl(struct file *filp,
> + unsigned int ioctl, unsigned long arg);
> +__init void kvm_arch_init(void);
> +
> static inline int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva,
>u32 error_code)
> {
> Index: kvm/drivers/kvm/Makefile
> ===
> --- kvm.orig/drivers/kvm/Makefile 2007-10-10 11:35:01.0 +0200
> +++ kvm/drivers/kvm/Makefile 2007-10-10 14:36:36.0 +0200
> @@ -2,7 +2,7 @@
> # Makefile for Kernel-based Virtual Machine module
> #
>
> -kvm-objs := kvm_main.o mmu.o x86_emulate.o i8259.o irq.o lapic.o ioapic.o
> +kvm-objs := kvm_main.o x86.o mmu.o x86_emulate.o i8259.o irq.o lapic.o
> ioapic.o
> obj-$(CONFIG_KVM) += kvm.o
> kvm-intel-objs = vmx.o
> obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
> Index: kvm/drivers/kvm/kvm_main.c
> ===
> --- kvm.orig/drivers/kvm/kvm_main.c 2007-10-10 11:34:07.0 +0200
> +++ kvm/drivers/kvm/kvm_main.c2007-10-10 16:57:05.0 +0200
> @@ -16,6 +16,7 @@
> */
>
> #include "kvm.h"
> +#include "x86.h"
> #include "x86_emulate.h"
> #include "segment_descriptor.h"
> #include "irq.h"
> @@ -45,7 +46,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> MODULE_AUTHOR("Qumranet");
> @@ -2518,43 +2518,6 @@
> EXPORT_SYMBOL_GPL(kvm_get_cs_db_l_bits);
>
> /*
> - * List of msr numbers which we expose to userspace through KVM_GET_MSRS
> - * and KVM_SET_MSRS, and KVM_GET_MSR_INDEX_LIST.
> - *
> - * This list is modified at module load time to reflect the
> - * capabilities of the host cpu.
> - */
> -static u32 msrs_to_save[] = {
> - MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
> - MSR_K6_STAR,
> -#ifdef CONFIG_X86_64
> - MSR_CSTAR, MSR_KERNEL_GS_BASE, MSR_SYSCALL_MASK, MSR_LSTAR,
> -#endif
> - MSR_IA32_TIME_STAMP_COUNTER,
> -};
> -
> -static unsigned num_msrs_to_save;
> -
> -static u32 emulated_msrs[] = {
> - MSR_IA32_MISC_ENABLE,
> -};
> -
> -static __init void kvm_init_msr_list(void)
> -{
> - u32 dummy[2];
> - unsigned i, j;
> -
> - for (i = j = 0; i < ARRAY_SIZE(msrs_to_save); i++) {
> - if (rdmsr_safe(msrs_to_save[i], &dummy[0], &dummy[1]) < 0)
> - continue;
> - if (j < i)
> - msrs_to_save[j] = msrs_to_save[i];
> - j++;
> - }
> - num_msrs_to_save = j;
> -}
> -
> -/*
> * Adapt set_msr() to msr_io()'s calling convention
> */
> static int do_set_msr(struct kvm_vcpu *vcpu, unsigned index, u64 *data)
> @@ -3366,57 +3329,25 @@
>
[kvm-devel] [Patch][2/3]
>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 different meanings. In the third patch, we add a sub field struct kvm_arch_ops for arch-specific ops. That is, different CPU archs can define its arch-specific ops for its special need. IMO, we should treat x86, IA64, ppc etc as different archtiectures, other than see vmx, svm as different archs. svm and vmx should be two different virtualization approaches for x86 arch from the point view of platforms. 0002-Change-kvm_x86_ops-to-kvm_ops-and-make-room-for.patch Description: 0002-Change-kvm_x86_ops-to-kvm_ops-and-make-room-for.patch - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [Patch] [0/3] Patches to support new architectures.
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 code, and also add an include dir for managing header files. Then, some structures, such as kvm_vcpu, struct kvm_arch_ops(changed to kvm_ops) are extended with an sub field *arch to accommodate arch-specific data fields wtih different architectures. 1. move_files.patch : Move all files to its final position in the soruce structure. No any code logic changed. 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 ops. That is, different CPU archs can define its arch-specific ops for its special need. IMO, we should treat x86, IA64, ppc etc as different archtiectures, other than see vmx, svm as different archs. svm and vmx should be two different virtualization approaches for x86 arch from the point view of platforms. 3. re-frame.patch. This patch is the main work to to support differnt architectures. it includes: (1). Split kvm_main.c to kvm_arch.c and new kvm_main.c. kvm_arch.c under x86 directory contains arch-specific code, and new kvm_main.c only holds interfaces with user space, and basic kvm infrastructure. Split some functions to make them arch-independent. (2) Add an include directory to hold head files, and split kvm.h to two parts. One is kvm_arch.h to deposit some arch-specfic structures, such as struct kvm_vcpu_arch, kvm_arch_ops etc, some arch-dependent macros and functions declares. (3) Add arch support for structure kvm_ops, and structure kvm_vcpu. (4) Make file change. By the way, maybe more changes are needed in furture when real new architecture in. Perhaps, some current arch-independent code today will be thought as arch-specific ones, vice versa. Anyway, we these changes are basically necessary for our re-frame work. Only these changes in, then we can carry out further work. These patches are based on commit 7060e1c92b504ac725e2ffbc91053c1dc684e685(last commit of Oct 8). Due to big changes to code structure, these pathes will be out of date soon. So, we have to make the desicion ASAP, or it is very painful to rebase them. Basically, these patches have no more code logic and functionality changes. And I have tested them on our platforms. Works well on 32bit and 64bit platforms. Todo List: split include/linux/kvm.h & kvm_para.h(Not urgent until real other archs in.). Userspace compile infrastructure change accordingly. Any comments are welcome! Thanks Xiantao - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] soft lockup after stop/cont
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 cpu may be scheduled away while a timer runs down. I don't think there's anything kvm could do better regerding the soft lockup code. Soft lockup is just broken for virtualized environments and needs to be fixed. For the time being, just disable it in kconfig. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Hacking QEMU/KVM to use unused graphics adapters
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 hacking >> > in the ability to utilize this second video card (one not utilized by >> > the host Linux)? And in the situation of a laptop, would it be possible >> > to boot the host Linux in a way that it would not utilize the video >> > card, but get a qemu guest to use it? >> > Theoretically, there's no reason this isn't possible, right? >> >> We need something like a "PCI proxy" allowing to route some I/O to >> virtual PCI >> devices and others to real PCI devices. Moreover we must be able to >> inform host >> kernel to not manage a given PCI card (or be able to hot unplug it >> from host >> kernel PCI structures) >> > 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 works but > I'm > not sure about the features required from VGA pass through. > Dor. Perhaps if we use host IOMMU we don't need pv DMA ? How do you say to host to not manage a PCI devices and let the guest managing it ? Laurent -- [EMAIL PROTECTED] - "Given enough eyeballs, all bugs are shallow" E. S. Raymond signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Working on an entry-level project
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 would be of use? You may choose the interactivity improvements:in http://kvm.qumranet.com/kvmwiki/TODO Dor - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Hacking QEMU/KVM to use unused graphics adapters
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 utilize this second video card (one not utilized by > > the host Linux)? And in the situation of a laptop, would it be possible > > to boot the host Linux in a way that it would not utilize the video > > card, but get a qemu guest to use it? > > Theoretically, there's no reason this isn't possible, right? > > We need something like a "PCI proxy" allowing to route some I/O to > virtual PCI > devices and others to real PCI devices. Moreover we must be able to > inform host > kernel to not manage a given PCI card (or be able to hot unplug it > from host > kernel PCI structures) > 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 works but I'm not sure about the features required from VGA pass through. Dor. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Hacking QEMU/KVM to use unused graphics adapters
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 (one not utilized by > the host Linux)? And in the situation of a laptop, would it be possible > to boot the host Linux in a way that it would not utilize the video > card, but get a qemu guest to use it? > Theoretically, there's no reason this isn't possible, right? We need something like a "PCI proxy" allowing to route some I/O to virtual PCI devices and others to real PCI devices. Moreover we must be able to inform host kernel to not manage a given PCI card (or be able to hot unplug it from host kernel PCI structures) Laurent -- [EMAIL PROTECTED] - "Given enough eyeballs, all bugs are shallow" E. S. Raymond signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] OpenBSD 4.1 failes with kvm-45
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: malformed patch at line 6: DisplayState
> *ds,
> const char **fd_filename, int snapshot,
>
> regards, Oliver
I might be wrong, but this sounds like a patch gone bad by the mail
system, since here I get clean and quite patch relative to both kvm-45
and kvm-46. I'll try to resend as attachment.
Regards,
Dan.
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 4d0bb93..bf4d35a 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -683,7 +683,7 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
int boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
- int pci_enabled)
+ int pci_enabled, const char *cpu_model)
{
char buf[1024];
int ret, linux_boot, i;
@@ -705,6 +705,13 @@ static void pc_init1(ram_addr_t ram_size, int
vga_ram_size, int boot_device,
linux_boot = (kernel_filename != NULL);
/* init CPUs */
+if (cpu_model == NULL)
+cpu_model = "basic";
+
+if (x86_find_cpu_by_name(cpu_model)) {
+fprintf(stderr, "Unable to find x86 CPU definition\n");
+exit(1);
+}
for(i = 0; i < smp_cpus; i++) {
env = cpu_init();
if (i != 0)
@@ -1008,7 +1015,7 @@ static void pc_init_pci(ram_addr_t ram_size, int
vga_ram_size, int boot_device,
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
}
static void pc_init_isa(ram_addr_t ram_size, int vga_ram_size, int boot_device,
@@ -1022,7 +1029,7 @@ static void pc_init_isa(ram_addr_t ram_size, int
vga_ram_size, int boot_device,
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
}
QEMUMachine pc_machine = {
diff --git a/qemu/target-i386/cpu.h b/qemu/target-i386/cpu.h
index de2669e..7517699 100644
--- a/qemu/target-i386/cpu.h
+++ b/qemu/target-i386/cpu.h
@@ -280,21 +280,56 @@
#define CPUID_CMOV (1 << 15)
#define CPUID_PAT (1 << 16)
#define CPUID_PSE36 (1 << 17)
+#define CPUID_PN (1 << 18)
#define CPUID_CLFLUSH (1 << 19)
-/* ... */
+#define CPUID_DTS (1 << 21)
+#define CPUID_ACPI (1 << 22)
#define CPUID_MMX (1 << 23)
#define CPUID_FXSR (1 << 24)
#define CPUID_SSE (1 << 25)
#define CPUID_SSE2 (1 << 26)
+#define CPUID_SS (1 << 27)
+#define CPUID_HT (1 << 28)
+#define CPUID_TM (1 << 29)
+#define CPUID_IA64 (1 << 30)
+#define CPUID_PBE (1 << 31)
#define CPUID_EXT_SSE3 (1 << 0)
#define CPUID_EXT_MONITOR (1 << 3)
+#define CPUID_EXT_DSCPL(1 << 4)
+#define CPUID_EXT_VMX (1 << 5)
+#define CPUID_EXT_SMX (1 << 6)
+#define CPUID_EXT_EST (1 << 7)
+#define CPUID_EXT_TM2 (1 << 8)
+#define CPUID_EXT_SSSE3(1 << 9)
+#define CPUID_EXT_CID (1 << 10)
#define CPUID_EXT_CX16 (1 << 13)
+#define CPUID_EXT_XTPR (1 << 14)
+#define CPUID_EXT_DCA (1 << 17)
+#define CPUID_EXT_POPCNT (1 << 22)
#define CPUID_EXT2_SYSCALL (1 << 11)
+#define CPUID_EXT2_MP (1 << 19)
#define CPUID_EXT2_NX (1 << 20)
+#define CPUID_EXT2_MMXEXT (1 << 22)
#define CPUID_EXT2_FFXSR (1 << 25)
+#define CPUID_EXT2_PDPE1GB (1 << 26)
+#define CPUID_EXT2_RDTSCP (1 << 27)
#define CPUID_EXT2_LM (1 << 29)
+#define CPUID_EXT2_3DNOWEXT (1 << 30)
+#define CPUID_EXT2_3DNOW (1 << 31)
+
+#define CPUID_EXT3_LAHF_LM (1 << 0)
+#define CPUID_EXT3_CMP_LEG (1 << 1)
+#define CPUID_EXT3_SVM (1 << 2)
+#define CPUID_EXT3_EXTAPIC (1 << 3)
+#define CPUID_EXT3_CR8LEG (1 << 4)
+#define CPUID_EXT3_ABM (1 << 5)
+#define CPUID_EXT3_SSE4A (1 << 6)
+#define CPUID_EXT3_MISALIGNSSE (1 << 7)
+#define CPUID_EXT3_3DNOWPREFETCH (1 << 8)
+#define CPUID_EXT3_OSVW(1 << 9)
+#define CPUID_EXT3_IBS (1 << 10)
#define CPUID_EXT3_SVM (1 << 2)
@@ -581,6 +616,9 @@ typedef struct CPUX86State {
CPUX86State *cpu_x86_init(void);
int cpu_x86_exec(CPUX86State *s);
void cpu_x86_close(CPUX86State *s);
+int x86_find_cpu_by_name (const unsigned char *name);
+void x86_cpu_list (FILE *f, int (*cpu_fprintf)(FILE *f, const char *fmt,
+ ...));
int cpu_get_pic_interrupt(CPUX86State *s);
/* MSDOS compatibility mode FPU exception support */
void cpu_set_ferr(CPUX86State *s);
diff --git a/qemu/target-i386/helper2.c b/qemu/target-i386/helper2.c
index b0e9692..ca8d5ed 100644
--- a/qemu/targ
Re: [kvm-devel] kernel device reset support
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 doesn't back to user for a long time.
BTW, XEN support reset by re-start Qemu-DM and guest,
which is quit simple and without additional issues.
But KVM decide to do within Qemu. There are many ways
a guest can do reboot such as tripple fault, port CF9 write etc.
keyboard write etc. Current Qemu only handle keyboard
port (0x61) reset method. We can add tripple fault reboot
support in future.
thx,eddie
diff --git a/qemu/vl.c b/qemu/vl.c
index 634fb34..b65b165 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7265,7 +7265,7 @@ int main_loop(void)
ret = EXCP_INTERRUPT;
break;
}
-if (reset_requested) {
+if (reset_requested && env->cpu_index == 0) {
reset_requested = 0;
qemu_system_reset();
#ifdef USE_KVM
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
