Re: [kvm-devel] Balloon driver?
>> >I want to try the balloon driver. Do we have it in any git tree? >> > >> >The git tree I am having now only has master branch, and nothing else. >> > >> >(Maybe the balloon driver is not working yet, but I am curious when >> >see the userspace code in user/) >> > >> >Thanks, >> >Jun >> >> You're welcome to test it, it is under >> git://kvm.qumranet.com/home/dor/src/linux-2.6 >> Checkout the build-trunk branch. >> >> I don't have the time to merge it currently. Note that there are also >> some more balloon drivers for other architecture (s390). >> >> The Linux guest driver change the balloon size using a simple char >> device. > >Now I see the userspace tool again, and it seems it must be used from >inside the guest?? That's right. That's the Linux guest side implementation. For windows we use the vmchannel option in qemu (qemu/hw/hypercall) interface. It is a qemu device from the host side that can be connected to tcp/unix socket. The guest sees it as a pci device. Both ends can define any protocol over the channel. So our windows guest passes balloon inflate/deflate commands/acks. What's your motivation of ballooning? If it's important I can add the pci interface + push it upstream. > >So we cannot balloon up/down a guest from host machine? > >I will try to see if it works. > >Thanks, >Jun - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
On 6/6/07, Dor Laor <[EMAIL PROTECTED]> wrote: > >> >I want to try the balloon driver. Do we have it in any git tree? > >> > > >> >The git tree I am having now only has master branch, and nothing > else. > >> > > >> >(Maybe the balloon driver is not working yet, but I am curious when > >> >see the userspace code in user/) > >> > > >> >Thanks, > >> >Jun > >> > >> You're welcome to test it, it is under > >> git://kvm.qumranet.com/home/dor/src/linux-2.6 > >> Checkout the build-trunk branch. > >> > >> I don't have the time to merge it currently. Note that there are also > >> some more balloon drivers for other architecture (s390). > >> > >> The Linux guest driver change the balloon size using a simple char > >> device. > > > >Now I see the userspace tool again, and it seems it must be used from > >inside the guest?? > > That's right. That's the Linux guest side implementation. > For windows we use the vmchannel option in qemu (qemu/hw/hypercall) > interface. It is a qemu device from the host side that can be connected > to tcp/unix socket. The guest sees it as a pci device. > Both ends can define any protocol over the channel. > > So our windows guest passes balloon inflate/deflate commands/acks. > > What's your motivation of ballooning? If it's important I can add the > pci interface + push it upstream. I looked at the current balloon driver of Linux, and really I dont like it. Why we have a different solution from Windows'? It is better we have the same way of implementing it on different OS. So the PCI interface is definetely better IMO. Please put it online, so we can test it. Thanks, Jun - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] vista install oddities
Avi Kivity wrote: > Wayde Milas wrote: > >> This is a weird one. Using kvm27. I am able to install and run winxp 32 >> bit perfectly. The problem arises when I try and run my Vista Ultimate >> upgrade. You cannot cold boot the upgrade and install on a blank drive >> because when you enter the activation code, the software checks to make >> sure there is a valid version of windows already installed. >> >> Let me outline the way it works: >> >> Base metal: >> * Empty drive, vista installer will gripe that there is no windows >> installed and that the key entered is for upgrade only. >> * Windows installed installer will upgrade. >> >> kvm/quem >> * Empty drive, vista installer will gripe that it cannot verify the >> entered key. Note that its not saying that its a bad key. >> * Windows installed installer grips that it cannot verify the entered key. >> >> I'm at a loss on how to debug this one. It obviously has something to do >> with kvm/quem since the process works when running native. >> >> > > This is probably some kind of copy protection device, it's making sure > you're upgrading to the same machine and not to a different one. So > most likely this is by design. > > > Maybe... but define "different one". The ultimate upgrade comes with its own unique key and the only restriction that applies is that it must be installed upon a working windows install. Something else I just tried. When not in kvm on an install I can hit next and NOT put a key. I get a popup warning me that I'll have to put in a key withing 30 days or the os will cease to function and I hit ok to proceed. Inside kvm if I do the same thing I get the same popup, hit proceed, and I'm taken right back to the key activation screen and am not able to proceed. Is it possible vista detects that its running virtulized and prevents any install because of it? - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
Jun Koi wrote: > So the PCI interface is definetely better IMO. Please put it online, > so we can test it. Why would we want a PCI interface to do balooning? All we need is a simple interface. It _is_ a mess for platforms that don't have PCI. And it is a mess for paravirtulaization - will we create a virtual PCI bus just for this? so long, Carsten - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] vista install oddities
Wayde Milas wrote: > >> >> This is probably some kind of copy protection device, it's making sure >> you're upgrading to the same machine and not to a different one. So >> most likely this is by design. >> > Maybe... but define "different one". The ultimate upgrade comes with > its own unique key and the only restriction that applies is that it > must be installed upon a working windows install. I don't know anything about this really. > > Something else I just tried. When not in kvm on an install I can hit > next and NOT put a key. I get a popup warning me that I'll have to put > in a key withing 30 days or the os will cease to function and I hit ok > to proceed. > > Inside kvm if I do the same thing I get the same popup, hit proceed, > and I'm taken right back to the key activation screen and am not able > to proceed. > > Is it possible vista detects that its running virtulized and prevents > any install because of it? > Maybe. Non-upgrade installs do work. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
>Jun Koi wrote: >> So the PCI interface is definetely better IMO. Please put it online, >> so we can test it. >Why would we want a PCI interface to do balooning? All we need is a >simple interface. It _is_ a mess for platforms that don't have PCI. >And it is a mess for paravirtulaization - will we create a virtual PCI >bus just for this? I agree that pci interface isn't ideal, the advantage is that platforms that do support pci don't have to implement a virtualized bus, and pci is PnP device. This was the motivation behind using it, especially for Windows. Now that more platforms are joining the KVM wagon, we should define a common bus. PCI was a overkill anyway - its irq are shared and we don't have to use its io/mmio areas. Do you guys have something to start with? > >so long, >Carsten - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
Dor Laor wrote: > I agree that pci interface isn't ideal, the advantage is that platforms > that do support pci don't have to implement a virtualized bus, and pci > is PnP device. This was the motivation behind using it, especially for > Windows. In understand that requirement, and I think being able to surface paravirtual functions/devices to the guest as PCI device needs to be a key feature. For windows guests. > Now that more platforms are joining the KVM wagon, we should define a > common bus. PCI was a overkill anyway - its irq are shared and we don't > have to use its io/mmio areas. > Do you guys have something to start with? We do have something basic, our vdev bus. The bad thing is, it is platform specific. I really prefer to aim for an idea that Arnd came up with when discussing this issue: We could define a virtual device bus. We would have platform specific bus implementations which rely on hypercalls, interrupts, and shared memory in the pure paravirtual case. And we need a second bus driver, which is based on a pci device. Just similar to the situation where a PCI device is a USB host adapter. Now functionality like device drivers can sit on top of the abstraction layer. We need to invent a similar abstraction on the hypervisor side, which is a tricky task indeed. The best approach into this direction I have seen so far is not our own vdev thing but Rusty's virtio infrastructure. That's what I think I would start with. so long, Carsten - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
Carsten Otte wrote: > The best approach into this direction I have seen so far is not our > own vdev thing but Rusty's virtio infrastructure. That's what I think > I would start with. > > I agree. We need a Lego set containing the following bricks: - bus interfaces: pci bus, hypercall-based bus, xenbus - functionality: net driver, block driver - virtio data path: xen rings + grant tables + event channels, kvm rings + kmap_atomic + interrupts So you can write a 4-line driver that glues the pci bus interface to the net functionality driver to kvm virtio backend, and take the rest of the day off. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
On Wednesday 06 June 2007, Carsten Otte wrote: > Dor Laor wrote: > > > Now that more platforms are joining the KVM wagon, we should define a > > common bus. PCI was a overkill anyway - its irq are shared and we don't > > have to use its io/mmio areas. > > Do you guys have something to start with? > We do have something basic, our vdev bus. The bad thing is, it is > platform specific. I really prefer to aim for an idea that Arnd came > up with when discussing this issue: > We could define a virtual device bus. I guess, more specifically, you mean a bus_type in Linux terminology. > Now functionality like device drivers can sit on top of the > abstraction layer. We need to invent a similar abstraction on the > hypervisor side, which is a tricky task indeed. > The best approach into this direction I have seen so far is not our > own vdev thing but Rusty's virtio infrastructure. That's what I think > I would start with. So you suggest having a PCI driver that exports a virtio device for each PCI device it matches? Sounds fine to me, though it goes beyond what I think Rusty had in mind with his latest set of virtio patches. Note that contrary to what I may have said previously, I think that such a virtio device on top of a PCI device need not use any PCI specific APIs (readl/writel, pci_map_*, ioremap_, pci_dev->irq, ...) but could do all of that by means of a hypercall interface. The only real point we want to use PCI for is to find out about the existence of a device and to get an identifier that gets passed to the hypercalls. Arnd <>< - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
On 6/7/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > Carsten Otte wrote: > > The best approach into this direction I have seen so far is not our > > own vdev thing but Rusty's virtio infrastructure. That's what I think > > I would start with. > > > > > > I agree. We need a Lego set containing the following bricks: > > - bus interfaces: pci bus, hypercall-based bus, xenbus > - functionality: net driver, block driver > - virtio data path: xen rings + grant tables + event channels, kvm rings > + kmap_atomic + interrupts > Avi, may you explain what is the role of the "bus interface" in the whole picture? To autodetect and probe new virtual device?? About the balloon driver, I looked at the current code, and what I dont like is its approach: it needs to be operated from inside the guest, which is not the way we usually want to do. So something like Xen balloon driver is certainly better. Dor, why dont you get the idea from Xen balloon, but take your way? Thanks, Jun - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
Arnd Bergmann wrote: > On Wednesday 06 June 2007, Carsten Otte wrote: >> We do have something basic, our vdev bus. The bad thing is, it is >> platform specific. I really prefer to aim for an idea that Arnd came >> up with when discussing this issue: >> We could define a virtual device bus. > > I guess, more specifically, you mean a bus_type in Linux terminology. Indeed, sorry for the confusion. > So you suggest having a PCI driver that exports a virtio device for > each PCI device it matches? Sounds fine to me, though it goes beyond > what I think Rusty had in mind with his latest set of virtio > patches. We don't need a PCI device per virtio device. We can have a PCI device that is a virtio bus driver. > Note that contrary to what I may have said previously, I think that > such a virtio device on top of a PCI device need not use any PCI > specific APIs (readl/writel, pci_map_*, ioremap_, pci_dev->irq, ...) > but could do all of that by means of a hypercall interface. The > only real point we want to use PCI for is to find out about the > existence of a device and to get an identifier that gets passed > to the hypercalls. True. We need to abstract how things get passed. Simple primitives, but good enough to provide all functionality needed by the exploiters. See Avis Lego box. so long, Carsten - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
Jun Koi wrote: > On 6/7/07, Avi Kivity <[EMAIL PROTECTED]> wrote: >> Carsten Otte wrote: >> > The best approach into this direction I have seen so far is not our >> > own vdev thing but Rusty's virtio infrastructure. That's what I think >> > I would start with. >> > >> > >> >> I agree. We need a Lego set containing the following bricks: >> >> - bus interfaces: pci bus, hypercall-based bus, xenbus >> - functionality: net driver, block driver >> - virtio data path: xen rings + grant tables + event channels, kvm rings >> + kmap_atomic + interrupts >> > > Avi, may you explain what is the role of the "bus interface" in the > whole picture? To autodetect and probe new virtual device?? > Yes. I guess the most important part is to advertise the interrupt line correctly to the guest OS, so it can apply its policies wrt sharing and priorities as it wishes. Hotplug/unplug and autodetection are also important, but can probably be hacked even without pci. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
Carsten Otte wrote: > >> So you suggest having a PCI driver that exports a virtio device for >> each PCI device it matches? Sounds fine to me, though it goes beyond >> what I think Rusty had in mind with his latest set of virtio >> patches. >> > We don't need a PCI device per virtio device. We can have a PCI device > that is a virtio bus driver. > > I think it is better to have a pci device per, er, device. It's nice to be able to do lspci (on an older Linux distro) and see what devices you have, instead of requiring a new tool. It will also not require us to backport the virtual bus to older kernels. Newer kernels can of course use a hypercall-based bus (suggestion: one hypercall that reads an array of structures, each describing one device, and one interrupt that means "please issue that hypercall and take notice of any changes that may have occurred since the last time you did that"). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] KVM - Fix rmode_tss_base declaration
The long return value of rmode_tss_base is truncated by its declared
return type of int.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
drivers/kvm/vmx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: kvm/drivers/kvm/vmx.c
===
--- kvm.orig/drivers/kvm/vmx.c
+++ kvm/drivers/kvm/vmx.c
@@ -884,7 +884,7 @@ static void enter_pmode(struct kvm_vcpu
vmcs_write32(GUEST_CS_AR_BYTES, 0x9b);
}
-static int rmode_tss_base(struct kvm* kvm)
+static unsigned long rmode_tss_base(struct kvm* kvm)
{
gfn_t base_gfn = kvm->memslots[0].base_gfn + kvm->memslots[0].npages -
3;
return base_gfn << PAGE_SHIFT;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
On Wednesday 06 June 2007, Jun Koi wrote: > About the balloon driver, I looked at the current code, and what I > dont like is its approach: it needs to be operated from inside the > guest, which is not the way we usually want to do. So something like > Xen balloon driver is certainly better. There are multiple fundamentally different approaches. Three of these have been used on s390 with success, and they are not mutually exclusive: 1. Balloning: The guest voluntarily gives up pages using an hcall if it has free pages or is told to do so by the hypervisor. 2. pfault: The host takes away pages from the guest based on LRU. When the guest accesses a page that has been paged out by the host, it gets an exception and has the chance to switch the guest task. Another exception is delivered when the page is there, and the task gets marked runnable again. 3. "cmm2": The guest annotages every page as 'unused', 'stable', 'volatile' or 'potentially volatile', and the host memory management code can take these into consideration. See https://ols2006.108.redhat.com/reprints/schwidefsky-reprint.pdf for details. Arnd <>< - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kvm-27 kernel oops
Hi,
I just tried kvm-27 with the following result when starting a vm.
-no-kvm works, as does kvm-26. No other changes to my set up:
BUG: unable to handle kernel NULL pointer dereference at virtual address
0024
printing eip:
f8d16ee7
*pde =
Oops: 0002 [#1]
PREEMPT SMP
Modules linked in: kvm_intel kvm i915 drm acpi_cpufreq freq_table rfcomm l2cap
bluetooth button ac battery iptable_raw xt_comment xt_policy xt_multiport
ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_REJECT ipt_recent ipt_owner ipt_LOG
ipt_iprange ipt_ECN ipt_ecn ipt_ah ipt_addrtype xt_tcpmss xt_pkttype xt_NFQUEUE
xt_NFLOG xt_MARK xt_mark xt_mac xt_limit xt_length xt_helper xt_hashlimit
xt_dccp xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY xt_tcpudp xt_state
nf_conntrack_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter
ip_tables x_tables tun bridge llc dock thinkpad_acpi hwmon backlight loop
mmc_block snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_timer sdhci snd
mmc_core psmouse yenta_socket rsrc_nonstatic i2c_i801 pcmcia_core i2c_core
intel_agp agpgart soundcore snd_page_alloc evdev sha256 usbhid hid ehci_hcd
usbcore e1000 sd_mod thermal processor fan
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010206 (2.6.22-rc3-20070531-1 #1)
EIP is at mmu_free_roots+0x47/0x90 [kvm]
eax: ebx: ecx: 32560001 edx: 0064ac00
esi: 0008 edi: f229109c ebp: f229 esp: f2527e98
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process qemu (pid: 6147, ti=f2526000 task=f2874000 task.ti=f2526000)
Stack: f229109c fff5 f8d16fb1 f229109c f8d18128 f229109c f8d14d78
f2527ed8 c034ea98 0020 0010 0010 0020
0002 f2290068 0020 000fffe0 0080 f2290040 0002 c17f18e0
Call Trace:
[] destroy_kvm_mmu+0x21/0x40 [kvm]
[] kvm_mmu_reset_context+0x8/0x30 [kvm]
[] kvm_vm_ioctl+0x758/0x830 [kvm]
[] __atomic_notifier_call_chain+0x26/0x50
[] kvm_vm_ioctl+0x0/0x830 [kvm]
[] do_ioctl+0x2b/0x90
[] do_page_fault+0x333/0x620
[] vfs_ioctl+0x5c/0x290
[] sys_ioctl+0x3d/0x70
[] sysenter_past_esp+0x5f/0x85
[] packet_setsockopt+0x2b0/0x3b0
===
Code: 30 89 da 09 ca 74 2d 89 c8 89 da 81 e2 ff ff 0f 00 25 00 f0 ff ff 0f ac
d0 0c c1 ea 0c 89 c2 a1 00 b9 3c c0 c1 e2 05 8b 44 02 0c 48 24 8b 87 10 01
00 00 b9 ff ff ff ff c7 04 30 ff ff ff ff
EIP: [] mmu_free_roots+0x47/0x90 [kvm] SS:ESP 0068:f2527e98
note: qemu[6147] exited with preempt_count 1
BUG: scheduling while atomic: qemu/0x0001/6147
[] __sched_text_start+0x4f0/0x950
[] __pagevec_free+0x1d/0x30
[] release_pages+0x137/0x160
[] __mutex_lock_slowpath+0x52/0x90
[] mutex_lock+0xa/0x10
[] vcpu_load+0xb/0x20 [kvm]
[] kvm_free_vcpu+0x11/0x60 [kvm]
[] kvm_destroy_vm+0x4a/0x80 [kvm]
[] kvm_vm_release+0x8/0x10 [kvm]
[] __fput+0x97/0x160
[] kvm_vcpu_release+0x10/0x20 [kvm]
[] __fput+0x97/0x160
[] filp_close+0x49/0x80
[] put_files_struct+0x9c/0xc0
[] do_exit+0x129/0x7b0
[] die+0x250/0x260
[] do_page_fault+0x2e6/0x620
[] do_page_fault+0x0/0x620
[] error_code+0x72/0x78
[] mmu_free_roots+0x47/0x90 [kvm]
[] destroy_kvm_mmu+0x21/0x40 [kvm]
[] kvm_mmu_reset_context+0x8/0x30 [kvm]
[] kvm_vm_ioctl+0x758/0x830 [kvm]
[] __atomic_notifier_call_chain+0x26/0x50
[] kvm_vm_ioctl+0x0/0x830 [kvm]
[] do_ioctl+0x2b/0x90
[] do_page_fault+0x333/0x620
[] vfs_ioctl+0x5c/0x290
[] sys_ioctl+0x3d/0x70
[] sysenter_past_esp+0x5f/0x85
[] packet_setsockopt+0x2b0/0x3b0
===
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Balloon driver?
On Wed, 2007-06-06 at 19:17 +0300, Avi Kivity wrote: > Carsten Otte wrote: > > The best approach into this direction I have seen so far is not our > > own vdev thing but Rusty's virtio infrastructure. That's what I think > > I would start with. > > > > > > I agree. We need a Lego set containing the following bricks: > > - bus interfaces: pci bus, hypercall-based bus, xenbus > - functionality: net driver, block driver > - virtio data path: xen rings + grant tables + event channels, kvm rings > + kmap_atomic + interrupts > > So you can write a 4-line driver that glues the pci bus interface to the > net functionality driver to kvm virtio backend, and take the rest of the > day off. Speaking of which, I have been beavering away with various failed attempts, and finally ate humble pie and am implementing the simple callback scheme first suggested by Avi. Everything else made the drivers nasty and an efficient implementation nastier. Expect draft II patches within 24 hours... Rusty. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM - Fix rmode_tss_base declaration
> >The long return value of rmode_tss_base is truncated by its declared >return type of int. > >Signed-off-by: Jeff Dike <[EMAIL PROTECTED]> >-- > drivers/kvm/vmx.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >Index: kvm/drivers/kvm/vmx.c >=== >--- kvm.orig/drivers/kvm/vmx.c >+++ kvm/drivers/kvm/vmx.c >@@ -884,7 +884,7 @@ static void enter_pmode(struct kvm_vcpu > vmcs_write32(GUEST_CS_AR_BYTES, 0x9b); > } > >-static int rmode_tss_base(struct kvm* kvm) >+static unsigned long rmode_tss_base(struct kvm* kvm) Should use gpa_t instead. -Xin - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM - Fix rmode_tss_base declaration
On Thu, Jun 07, 2007 at 10:13:42AM +0800, Li, Xin B wrote: > >-static int rmode_tss_base(struct kvm* kvm) > >+static unsigned long rmode_tss_base(struct kvm* kvm) > > Should use gpa_t instead. Right you are, I didn't notice that type. Will fix. Jeff -- Work email - jdike at linux dot intel dot com - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM - Fix rmode_tss_base declaration
Jeff Dike wrote: > On Thu, Jun 07, 2007 at 10:13:42AM +0800, Li, Xin B wrote: > >>> -static int rmode_tss_base(struct kvm* kvm) >>> +static unsigned long rmode_tss_base(struct kvm* kvm) >>> >> Should use gpa_t instead. >> > > Right you are, I didn't notice that type. > > Some extra logic is needed on i386 with >= 4GB. Current code will wraparound since gfn_t is 32-bits long, but casting it to 64-bits is not the answer since the processor will truncate it back to 32 bits (the return value is eventually used as a long in enter_rmode()). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-27 kernel oops
Jon wrote:
> Hi,
>
> I just tried kvm-27 with the following result when starting a vm.
> -no-kvm works, as does kvm-26. No other changes to my set up:
>
>
This was fixed in kvm.git, use the attached patch (cd kernel/, and apply
with patch -p3).
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
commit 4b82b37a35a085a07d9ed84efee06c69655fd3d1
Author: Avi Kivity <[EMAIL PROTECTED]>
Date: Mon Jun 4 15:58:30 2007 +0300
KVM: Lazy guest cr3 switching
Switch guest paging context may require us to allocate memory, which
might fail. Instead of wiring up error paths everywhere, make context
switching lazy and actually do the switch before the next guest entry,
where we can return an error if allocation fails.
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 0632d0b..0fdd5a6 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -543,6 +543,8 @@ void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
const u8 *old, const u8 *new, int bytes);
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_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run);
@@ -554,6 +556,14 @@ static inline int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva,
return vcpu->mmu.page_fault(vcpu, gva, error_code);
}
+static inline int kvm_mmu_reload(struct kvm_vcpu *vcpu)
+{
+ if (likely(vcpu->mmu.root_hpa != INVALID_PAGE))
+ return 0;
+
+ return kvm_mmu_load(vcpu);
+}
+
static inline int is_long_mode(struct kvm_vcpu *vcpu)
{
#ifdef CONFIG_X86_64
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index 283df03..5915d7a 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -949,9 +949,7 @@ static int nonpaging_init_context(struct kvm_vcpu *vcpu)
context->free = nonpaging_free;
context->root_level = 0;
context->shadow_root_level = PT32E_ROOT_LEVEL;
- mmu_alloc_roots(vcpu);
- ASSERT(VALID_PAGE(context->root_hpa));
- kvm_arch_ops->set_cr3(vcpu, context->root_hpa);
+ context->root_hpa = INVALID_PAGE;
return 0;
}
@@ -965,11 +963,6 @@ static void paging_new_cr3(struct kvm_vcpu *vcpu)
{
pgprintk("%s: cr3 %lx\n", __FUNCTION__, vcpu->cr3);
mmu_free_roots(vcpu);
- if (unlikely(vcpu->kvm->n_free_mmu_pages < KVM_MIN_FREE_MMU_PAGES))
- kvm_mmu_free_some_pages(vcpu);
- mmu_alloc_roots(vcpu);
- kvm_mmu_flush_tlb(vcpu);
- kvm_arch_ops->set_cr3(vcpu, vcpu->mmu.root_hpa);
}
static void inject_page_fault(struct kvm_vcpu *vcpu,
@@ -1003,10 +996,7 @@ static int paging64_init_context_common(struct kvm_vcpu *vcpu, int level)
context->free = paging_free;
context->root_level = level;
context->shadow_root_level = level;
- mmu_alloc_roots(vcpu);
- ASSERT(VALID_PAGE(context->root_hpa));
- kvm_arch_ops->set_cr3(vcpu, context->root_hpa |
- (vcpu->cr3 & (CR3_PCD_MASK | CR3_WPT_MASK)));
+ context->root_hpa = INVALID_PAGE;
return 0;
}
@@ -1025,10 +1015,7 @@ static int paging32_init_context(struct kvm_vcpu *vcpu)
context->free = paging_free;
context->root_level = PT32_ROOT_LEVEL;
context->shadow_root_level = PT32E_ROOT_LEVEL;
- mmu_alloc_roots(vcpu);
- ASSERT(VALID_PAGE(context->root_hpa));
- kvm_arch_ops->set_cr3(vcpu, context->root_hpa |
- (vcpu->cr3 & (CR3_PCD_MASK | CR3_WPT_MASK)));
+ context->root_hpa = INVALID_PAGE;
return 0;
}
@@ -1042,7 +1029,6 @@ static int init_kvm_mmu(struct kvm_vcpu *vcpu)
ASSERT(vcpu);
ASSERT(!VALID_PAGE(vcpu->mmu.root_hpa));
- mmu_topup_memory_caches(vcpu);
if (!is_paging(vcpu))
return nonpaging_init_context(vcpu);
else if (is_long_mode(vcpu))
@@ -1064,16 +1050,31 @@ static void destroy_kvm_mmu(struct kvm_vcpu *vcpu)
int kvm_mmu_reset_context(struct kvm_vcpu *vcpu)
{
+ destroy_kvm_mmu(vcpu);
+ return init_kvm_mmu(vcpu);
+}
+
+int kvm_mmu_load(struct kvm_vcpu *vcpu)
+{
int r;
- destroy_kvm_mmu(vcpu);
- r = init_kvm_mmu(vcpu);
- if (r < 0)
- goto out;
+ spin_lock(&vcpu->kvm->lock);
r = mmu_topup_memory_caches(vcpu);
+ if (r)
+ goto out;
+ mmu_alloc_roots(vcpu);
+ kvm_arch_ops->set_cr3(vcpu, vcpu->mmu.root_hpa);
+ kvm_mmu_flush_tlb(vcpu);
out:
+ spin_unlock(&vcpu->kvm->lock);
return r;
}
+EXPORT_SYMBOL_GPL(kvm_mmu_load);
+
+void kvm_mmu_unload(struct kvm_vcpu *vcpu)
+{
+ mmu_free_roots(vcpu);
+}
static void mmu_pte_write_zap_pte(struct kvm_vcpu *vcpu,
struct kvm_mmu_page *page,
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index b621403..ed33f59 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -1482,6 +1482,10 @@ static int svm_vcpu_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
int r;
again:
+ r = kvm_mmu_reload(vcpu);
+ if (unlikely(r))
+ return r;
+
if (!vcpu->mmio_read_completed)
do_interrupt_requests(vcpu, kvm_run);
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 09e3609..a499989 100644
Re: [kvm-devel] kvm-27 kernel oops
Hi Avi,
On Thu, Jun 07, 2007 at 08:15:29AM +0300, Avi Kivity wrote:
> This was fixed in kvm.git, use the attached patch (cd kernel/, and apply
> with patch -p3).
Applied, but no go. Managed to save this before things started dying:
BUG: unable to handle kernel paging request at virtual address 30312030
printing eip:
c01712e9
*pde =
Oops: [#1]
SMP
Modules linked in: kvm_intel kvm i915 drm acpi_cpufreq freq_table rfcomm l2cap
bluetooth button ac battery iptable_raw xt_comment xt_policy xt_multiport
ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_REJECT ipt_recent ipt_owner ipt_LOG
ipt_iprange ipt_ECN ipt_ecn ipt_ah ipt_addrtype xt_tcpmss xt_pkttype xt_NFQUEUE
xt_NFLOG xt_MARK xt_mark xt_mac xt_limit xt_length xt_helper xt_hashlimit
xt_dccp xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY xt_tcpudp xt_state
nf_conntrack_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter
ip_tables x_tables tun bridge llc dock thinkpad_acpi hwmon backlight loop
mmc_block snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd sdhci
i2c_i801 i2c_core yenta_socket rsrc_nonstatic pcmcia_core mmc_core intel_agp
agpgart soundcore snd_page_alloc psmouse evdev sha256 sg sr_mod cdrom
usb_storage usbhid hid ehci_hcd usbcore e1000 sd_mod thermal processor fan
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010006 (2.6.22-rc4-20070607-1 #1)
EIP is at kmem_cache_alloc+0x39/0x70
eax: ebx: 0282 ecx: c159e080 edx: 30312030
esi: c03655a0 edi: 00d0 ebp: f753 esp: f7531f64
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process powersaved (pid: 4809, ti=f753 task=f74db900 task.ti=f753)
Stack: 5973 080cf840 ff9c fff4 c017cdd8 ff9c
f753 c017342e 0e6dc36e 46679a17 0e6dc36e 080cf840 1000
f753 c017352c 0e6dc36e c01040ba 080cf840 0e6dc36e
Call Trace:
[] getname+0x28/0xe0
[] do_sys_open+0x1e/0xe0
[] sys_open+0x1c/0x20
[] sysenter_past_esp+0x5f/0x85
===
Code: d7 8b 54 24 14 89 5c 24 08 9c 5b fa 64 a1 08 c0 39 c0 8b 8c 86 90 00 00
00 85 c9 74 28 8b 41 0c 85 c0 74 21 8b 51 0c 0f b7 41 0a <8b> 04 82 89 41 0c 53
9d 8b 5c 24 08 89 d0 8b 74 24 0c 8b 7c 24
EIP: [] kmem_cache_alloc+0x39/0x70 SS:ESP 0068:f7531f64
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
