Re: [kvm] [PATCH 13/16] kvm: enable MSI-X capabilty for assigned device
On Saturday 04 April 2009 05:27:43 Alex Williamson wrote:
On Tue, 2009-03-17 at 11:50 +0800, Sheng Yang wrote:
+if (*ctrl_word PCI_MSIX_ENABLE) {
+if (assigned_dev_update_msix_mmio(pci_dev) 0) {
+perror(assigned_dev_update_msix_mmio);
+return;
+}
+if (kvm_assign_irq(kvm_context, assigned_irq_data) 0) {
+perror(assigned_dev_enable_msix: assign irq);
+return;
+}
+assigned_dev-irq_requested_type = assigned_irq_data.flags;
+}
+}
Do we need some disable logic here? If I toggle a bnx2 NIC in a guest,
I get the following when it attempts to come back up:
MSI-X entry number is zero!
assigned_dev_update_msix_mmio: No such device or address
It seems that driver didn't fill the MMIO with any correct MSIX information,
or the program fail to intercept it after driver set enable bit of MSIX. It's
strange... (Have it got something to do with PM and some EXP feature you
mentioned?)
Could you enable DEVICE_ASSSIGNMENT_DEBUG=1 in qemu/hw/device-assignment.c and
post the output?
Thanks!
--
regards
Yang, Sheng
Thanks,
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] PCI pass-through fixups
On Tuesday 07 April 2009 08:02:10 Chris Wright wrote: * Alex Williamson (alex.william...@hp.com) wrote: I'm wondering if we need a spot for device specific fixups for PCI pass-through. In the example below, I want to expose a single port of an Intel 82571EB quad port copper NIC to a guest. It works great until I shutdown the guest, at which point the guest e1000e driver knows by the device ID that the NIC is a quad port, and blindly attempts to twiddle some bits on the bridge above it (that doesn't exist). And what happens? And the output of DEVICE_ASSIGNMENT_DEBUG=1 may help. And I don't have trouble here with another dual/quad port card by Intel, but not 82571EB. Obviously some robustness could be added to the driver, but would it make sense to do something like below and automatically remap these devices to identical single port device IDs? Thanks, Sounds quite fragile to me. Same here... We'd better to know what's happened. (wow, you even know the single port ones' device ID... :) ) -- regards Yang, Sheng -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
The compiling of lastest KVM user space code FAIL on the lastest kernel tree
HI,
when compiling kvm user space on the lastest kernel tree,
the compile FAIL; but on 2.6.29, this compile has succeeded.
The version of the lastest kernel tree is
[r...@fedora9 linux-2.6 {master}]$ git describe
v2.6.29-9854-gd508afb
[r...@fedora9 kvm-userspace {master}]$ make
...
rm -f include/asm include-compat/asm
ln -sf asm-x86 include/asm
ln -sf asm-x86 include-compat/asm
make -C /home/zwu/kernel/linux-2.6/ M=`pwd` \
LINUXINCLUDE=-I`pwd`/include -Iinclude \
\
-Iarch/x86/include -I`pwd`/include-compat \
-include include/linux/autoconf.h \
-include `pwd`/x86/external-module-compat.h
make[2]: Entering directory `/home/zwu/kernel/linux-2.6'
CC [M] /home/zwu/virt/kvm-userspace/kernel/x86/svm.o
In file included from /home/zwu/virt/kvm-userspace/kernel/x86/svm.c:57:
/home/zwu/virt/kvm-userspace/kernel/include/linux/kvm_host.h:191:
error: field \u2018mmu_notifier\u2019 has incomplete type
make[4]: *** [/home/zwu/virt/kvm-userspace/kernel/x86/svm.o] Error 1
make[3]: *** [/home/zwu/virt/kvm-userspace/kernel/x86] Error 2
make[2]: *** [_module_/home/zwu/virt/kvm-userspace/kernel] Error 2
make[2]: Leaving directory `/home/zwu/kernel/linux-2.6'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/zwu/virt/kvm-userspace/kernel'
make: *** [kernel] Error 2
It seems that the macro CONFIG_MMU_NOTIFIER is undefined in the
lastest kernel tree.
Cheers,
Zhiyong Wu
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU Limits on KVM?
cpu controller/group scheduler does not yet provide hard limit. In
case there are free resources available on your machine those will be
used by the processes running in the control groups in the ratio of
shares allocated to them. group scheduler provides proper fairness
only under contention.
You can try using cpusets to bind your VMs to a particular domain.
Though I have no hands on experience on doing that.
On Mon, Apr 6, 2009 at 4:24 PM, Oshrit Feder oshr...@il.ibm.com wrote:
Hi Francisco,
I've been trying to limit the cpu usage of a VM using cgroups - so I can
share my experience with you. However, from monitoring the kvm process
looks like it doesnt force a hard limit of cpu usage%. Hopefully, someone
can light up the issue.
I'm interested in limiting the io bandwidth of network and disk as well.
(dm-ioband - any experience with that? other suggestions?)
1. mount -t cgroup none /dev/cgroup -o cpu,memory
This creates the cgroup file system api on /dev/cgroup. The top level
hierarchy node contains all the processes by default.
2. cd /dev/cgroup
3. mkdir VM1
4. mkdir VM2
5. echo {kvm1 pid} vm1/tasks
6. echo {kvm2 pid} vm2/tasks
Moves the vm's processes from the top node to a child node - to enable
atomic control
7. edit VM1/cpu.shares and VM2/cpu.shares to change cpu proportion
(default is 1024 shares)
I've used 128 for VM1 and 1024 for VM2. To my understanding, that should
yield proportion of 128/(1024+128) 15% of cpu limit for VM1.
Each of the VMs was allocated 2 vcpu, the host has 4 cores.(Been tring the
same with 1 vcpu each, results werent different)
Monitoring results:
I used top, atop and system monitoring GUI on the host and on the guest
for monitoring. Was able to load VM1 to use more than 50%...
(Monitoring screenshot at http%3A%2F%2Ftinyurl.com%2Fcsx3v7 ) On the left
- guest monitoring, time graph shows that there are peaks of more than
50%), on the right - host monitoring, kvm pid 32620 (VM1 pid) with 63%
load)
Regarding the references you asked for. Those are the references I've
found and worked with:
www.mjmwired.net%2Fkernel%2FDocumentation%2Fcgroups.txt%A0
http%3A%2F%2Ftinyurl.com%2Fdcnoav
- Oshrit
oshr...@il.ibm.com
From:
Brian Jackson i...@theiggy.com
To:
Francisco Mazzeo francisco.maz...@gmail.com, kvm@vger.kernel.org
Date:
03/04/2009 02:32
Subject:
Re: CPU Limits on KVM?
I haven't ever really used cgroups. I always figured a fair host scheduler
is
good enough to handle spreading load. So I don't know if it will fit
exactly
what you need. I don't think so. I also don't know of any other options. I
will say, If I gave 4 VMs a single cpu each on a 4 core host, I would
expect
the host to be fully loaded. I wouldn't see any reason for the host not to
be
fully loaded. That is after all one of the key points of virtualization.
Better utilization of hardware.
On Thursday 02 April 2009 17:33:07 Francisco Mazzeo wrote:
Hello Brian,
Thanks for the reply. is there a wiki about cgroupds and how to set
them
up?
Also, I tried just for kicks to see what would happen if I create 4
Virtual Windows machines, run prime95 (a tool that does iterations
like superpi to stress test memory/cpu) on all of them and just assign
them only ONE core to them.
The server node did not crash and you are right, however I was hoping
for the server load to stay below 50% as I only gave it one single
core to each KVM VE. Instead it seems like KVM let each VE get one
slice of each of the 4 cores of my CPU, which did not accomplish what
I wanted.
Is cgroupds the only choice available?
-- Francisco
On Thu, Apr 2, 2009 at 3:29 PM, Brian Jackson i...@theiggy.com wrote:
There's CPU cgroups. It doesn't have exactly the ability you are
after,
but it is able to limit process(es) CPU usage. Maxing out CPU usage
won't
crash your server. The kernel will arbitrate sharing the CPU evenly
among
processes/VMs.
--Brian Jackson
On Thursday 02 April 2009 16:41:10 Francisco Mazzeo wrote:
Hello,
I am a new user to KVM and was wondering if there was any way to
limit a VE from using up all the resources of the processor.
Right now I have a Quad core 2.5Ghz, I have a KVM VE (running
windows
server 2003) and assigned 4 CPUs to it. If I max out the load for
that
VE, the entire host node load will be 100% which may crash it if I
hosted more than 1 single VE.
OpenVZ has cpulimit command, does KVM have something similar or any
way that I can implement a limit on a single VE? Say I want to only
give a max of 500Mhz per core, to total 2Ghz to the VE.
Thanks
Francisco
www.navigatoris.net / www.serversoutlet.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
RE: PCI passtthrought intel 82574L can't boot from disk
Hi, Currently, expansion ROM of assigned devices will be loaded into guest and execute. You can just comment out one line code (assigned_dev_load_option_rom() in qemu/hw/pc.c) to let qemu don't load expansion ROM, and then this issue should be gone. I met this issue before, but there was no problem when I assigned the same device to a guest in Xen which also load and execute expansion ROM. I guess it's caused by the difference between Xen guest bios and kvm guest bios. Regards, Weidong Hauke Hoffmann wrote: On Thursday 02 April 2009 18:58:26 you wrote: It is my understanding that you need vt-d/iommu support. I didn't think any existing amd chipsets had iommu support. You may want to look into that. Hi Brian, thanks for you response. I found a tool [1] from Intel to disable the Boot ROM on the nic. Thats resolves the boot problem. Regards Hauke [1] http://downloadcenter.intel.com/Detail_Desc.aspx?agr=YProductID=412DwnldID=8242 --Brian Jackson On Thursday 02 April 2009 07:00:07 Hauke Hoffmann wrote: Hi, qemu-system-x86_64 runs well and i can boot and run the guest system. Thats works very well. Command: /usr/local/kvm/bin/qemu-system-x86_64 -m 512 -hda /var/VM/roadrunner.local/hda.qcow2 -smp 1 -vnc 192.168.2.30: -net nic,macaddr=DE:AD:BE:EF:90:26 -net tap,ifname=tap0,script=no,downscript=no -boot c Then i tried to add an intel 82574L network adapter to the guest. Just the same command with addtionally -pcidevice host=07:00.0 Then i connected via VNC and see BIOS startpage and the following lines: Initializing Intel(r) boot agent ge v1.3.21 pxe 2.1 build 086 (WfM 2.0) Press f12 for moot menu You can see a screenshot at http://nxt7.de/download/qemu.png The guests keep on this point and nothing changes. (I have wait hours.) I tried to press F12 in ThightVNC but no action. I must say that ThightVNC has problems with special chars (in my case). At this point, i need your help. Here are some details of my system Kernel: 2.6.29 form kernel.org (self compiled) kvm userspace: kvm-84 (self compiled) OS: Ubuntu 8.04.2 server r...@ls:~# lspci 00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3) 00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2) 00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) 00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) 00:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:09.0 Ethernet controller: Lite-On Communications Inc LNE100TX [Linksys EtherFast 10/100] (rev 25) 01:0a.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics Innovation) Volari Z7 06:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 03) 06:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 03) 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection r...@ls:~# lspci -tvvv -[:00]-+-00.0 nVidia Corporation MCP55 Memory Controller +-01.0 nVidia Corporation MCP55 LPC Bridge +-01.1 nVidia Corporation MCP55 SMBus +-02.0 nVidia Corporation MCP55 USB Controller +-02.1 nVidia Corporation MCP55 USB Controller +-04.0 nVidia Corporation MCP55 IDE +-05.0 nVidia Corporation MCP55 SATA Controller +-05.1 nVidia Corporation MCP55 SATA Controller +-05.2 nVidia Corporation MCP55 SATA Controller +-06.0-[:01]--+-09.0 Lite-On Communications Inc LNE100TX [Linksys EtherFast 10/100] | \-0a.0 XGI Technology
Re: [Qemu-devel] Changing the QEMU svn VERSION string
Hi,
I'd like to update the VERSION string in QEMU's svn tree. Right now,
it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing.
I don't want to make it 0.11.0 either because that's not going to be
reliable from a feature detection perspective. What I would like is to
make it 0.11.0-devel or something similar to that.
Maybe 0.10.99 ? Or 0.10.90, leaving the door open to number the 0.11
beta / rc versions (if any) 0.10.9{1,2,3}?
cheers,
Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Changing the QEMU svn VERSION string
On Mon, Apr 06, 2009 at 09:37:55PM -0500, Anthony Liguori wrote: Hi, I'd like to update the VERSION string in QEMU's svn tree. Right now, it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing. I don't want to make it 0.11.0 either because that's not going to be reliable from a feature detection perspective. What I would like is to make it 0.11.0-devel or something similar to that. Being the nice guy I am, I thought I would check that this didn't make libvirt go bonkers :-) This is the relevant detection code in libvirt: if (sscanf(help, QEMU PC emulator version %u.%u.%u (kvm-%u), major, minor, micro, kvm_version) != 4) kvm_version = 0; if (!kvm_version sscanf(help, QEMU PC emulator version u.%u.%u, major, minor, micro) != 3) goto cleanup2; If I change SVN to 0.11.0-devel, that's going to break the KVM string although the QEMU string will continue to work. Avi could potentially carry a patch to keep it 0.10.x and since kvm-%u will be used to identify features, that should keep things working. The only things we use the KVM version for are to decide whether migration and vnet_hdr flag for tun devices is supported. These checks are already outdated since 0.10.0 QEMU now has support for migration, and thus needs updating. So if you choose to go with '0.11.0-devel' it won't cause any huge problems for us, and I'll change this code to make it more forgiving of version number string changes in future. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: PCI hotplug and passthrough together supported?
hotplug is supported. You can refer to http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM. Regards, Weidong Aaron Dailey wrote: I'm interested in using PCI passthrough on a PCI device that may not be present at boot time, but is later inserted. Is this possible in KVM? I believe both passthrough and hotplug are individually supported, but I couldn't find an answer about hot plugging a device and then using it via passthrough. I'm not subscribed to the mailing list, so please copy me on replies. Thanks for your help, Aaron Dailey -- Aaron Dailey a...@alumni.virginia.edu -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] Cleanup vmx_intr_assist()
Signed-off-by: Gleb Natapov g...@redhat.com
---
arch/x86/kvm/vmx.c | 55
1 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 06252f7..9eb518f 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3309,6 +3309,34 @@ static void vmx_complete_interrupts(struct vcpu_vmx *vmx)
}
}
+static void vmx_intr_inject(struct kvm_vcpu *vcpu)
+{
+ /* try to reinject previous events if any */
+ if (vcpu-arch.nmi_injected) {
+ vmx_inject_nmi(vcpu);
+ return;
+ }
+
+ if (vcpu-arch.interrupt.pending) {
+ vmx_inject_irq(vcpu, vcpu-arch.interrupt.nr);
+ return;
+ }
+
+ /* try to inject new event if pending */
+ if (vcpu-arch.nmi_pending) {
+ if (vcpu-arch.nmi_window_open) {
+ vcpu-arch.nmi_pending = false;
+ vcpu-arch.nmi_injected = true;
+ vmx_inject_nmi(vcpu);
+ }
+ } else if (kvm_cpu_has_interrupt(vcpu)) {
+ if (vcpu-arch.interrupt_window_open) {
+ kvm_queue_interrupt(vcpu, kvm_cpu_get_interrupt(vcpu));
+ vmx_inject_irq(vcpu, vcpu-arch.interrupt.nr);
+ }
+ }
+}
+
static void vmx_intr_assist(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
bool req_int_win = !irqchip_in_kernel(vcpu-kvm)
@@ -3323,32 +3351,9 @@ static void vmx_intr_assist(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
GUEST_INTR_STATE_STI |
GUEST_INTR_STATE_MOV_SS);
- if (vcpu-arch.nmi_pending !vcpu-arch.nmi_injected) {
- if (vcpu-arch.interrupt.pending) {
- enable_nmi_window(vcpu);
- } else if (vcpu-arch.nmi_window_open) {
- vcpu-arch.nmi_pending = false;
- vcpu-arch.nmi_injected = true;
- } else {
- enable_nmi_window(vcpu);
- return;
- }
- }
-
- if (vcpu-arch.nmi_injected) {
- vmx_inject_nmi(vcpu);
- goto out;
- }
-
- if (!vcpu-arch.interrupt.pending kvm_cpu_has_interrupt(vcpu)) {
- if (vcpu-arch.interrupt_window_open)
- kvm_queue_interrupt(vcpu, kvm_cpu_get_interrupt(vcpu));
- }
-
- if (vcpu-arch.interrupt.pending)
- vmx_inject_irq(vcpu, vcpu-arch.interrupt.nr);
+ vmx_intr_inject(vcpu);
-out:
+ /* enable NMI/IRQ window open exits if needed */
if (vcpu-arch.nmi_pending)
enable_nmi_window(vcpu);
else if (kvm_cpu_has_interrupt(vcpu) || req_int_win)
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Kvm crash when I create a Guest
I'm Running Ubuntu 8.10, here is the command I use: kvm -net none -m 192 -no-acpi -hda ./gentoo_cleanvm.img.tar.lzma Dmesg Output: [ 7783.883426] [ cut here ] [ 7783.883440] kernel BUG at /build/buildd/linux-2.6.27/arch/x86/kvm/../../../virt/kvm/kvm_main.c:1528! [ 7783.883446] invalid opcode: [7] SMP [ 7783.883452] CPU 0 [ 7783.883457] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp kvm_amd kvm ipv6 af_packet rfcomm sco bridge stp bnep l2cap bluetooth ppdev powernow_k8 cpufreq_conservative cpufreq_ondemand cpufreq_stats cpufreq_powersave freq_table cpufreq_userspace sbs pci_slot container sbshc video output battery iptable_filter ip_tables x_tables ac lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq psmouse snd_timer evdev snd_seq_device serio_raw snd pcspkr k8temp soundcore snd_page_alloc i2c_piix4 i2c_core fglrx(P) parport_pc parport wmi button shpchp pci_hotplug ext3 jbd mbcache usb_storage libusual ata_generic sd_mod sr_mod crc_t10dif cdrom sg pata_atiixp ehci_hcd pata_acpi ohci_hcd ahci usbcore libata scsi_mod dock tg3 libphy thermal processor fan fbcon tileblit font bitblit softcursor fuse [ 7783.883588] Pid: 13480, comm: kvm Tainted: P D 2.6.27-11-generic #1 [ 7783.883593] RIP: 0010:[a0675132] [a0675132] kvm_handle_fault_on_reboot+0x12/0x30 [kvm] [ 7783.883634] RSP: 0018:8800735ddbd8 EFLAGS: 00010046 [ 7783.883639] RAX: 8800735e1000 RBX: 88007408bb00 RCX: [ 7783.883644] RDX: 88007408bb00 RSI: 8800735ddc0c RDI: 806e2a80 [ 7783.883648] RBP: 8800735ddbd8 R08: 880072d7a300 R09: [ 7783.883653] R10: 0001 R11: 0246 R12: 88007408bb00 [ 7783.883658] R13: ae80 R14: 8800735d7000 R15: 88007408c310 [ 7783.883663] FS: 44430950(0063) GS:806e2a80() knlGS:f6804b90 [ 7783.883668] CS: 0010 DS: ES: CR0: 8005003b [ 7783.883673] CR2: 7f8a03ee4000 CR3: 734fd000 CR4: 06e0 [ 7783.883678] DR0: DR1: DR2: [ 7783.883682] DR3: DR6: 0ff0 DR7: 0400 [ 7783.883687] Process kvm (pid: 13480, threadinfo 8800735dc000, task 880083034350) [ 7783.883692] Stack: 8800735ddc38 a06a0e19 807a7098 88007408bb00 [ 7783.883702] 0063dc28 803a875f 7408bb00 88007408bb58 [ 7783.883710] 88007408bb00 ae80 8800735d7000 88007408c310 [ 7783.883717] Call Trace: [ 7783.883734] [a06a0e19] svm_vcpu_run+0x1a9/0x3f0 [kvm_amd] [ 7783.883749] [803a875f] ? __up_read+0x8f/0xb0 [ 7783.883771] [a067d010] __vcpu_run+0x1f0/0x670 [kvm] [ 7783.883780] [8025afd9] ? recalc_sigpending+0x9/0x70 [ 7783.883800] [a067db2f] kvm_arch_vcpu_ioctl_run+0x8f/0x1f0 [kvm] [ 7783.883820] [a06755fa] kvm_vcpu_ioctl+0x2aa/0x490 [kvm] [ 7783.883829] [802c319e] ? handle_mm_fault+0x1ee/0x470 [ 7783.883837] [802e23a0] ? __slab_free+0x10/0x120 [ 7783.883844] [8025b9cd] ? __sigqueue_free+0x3d/0x50 [ 7783.883850] [8025b9cd] ? __sigqueue_free+0x3d/0x50 [ 7783.883857] [8025c99d] ? __dequeue_signal+0xed/0x210 [ 7783.883863] [8025afd9] ? recalc_sigpending+0x9/0x70 [ 7783.883869] [8025cc22] ? dequeue_signal+0x42/0x180 [ 7783.883875] [8025c47d] ? copy_siginfo_to_user+0x15d/0x210 [ 7783.883883] [802f8926] vfs_ioctl+0x36/0xb0 [ 7783.883888] [802f8c13] do_vfs_ioctl+0x273/0x2f0 [ 7783.883897] [80253e89] ? set_normalized_timespec+0x9/0x90 [ 7783.883903] [802f8d31] sys_ioctl+0xa1/0xb0 [ 7783.883912] [8021285a] system_call_fastpath+0x16/0x1b [ 7783.883916] [ 7783.883918] [ 7783.883920] Code: b9 df 31 c0 48 c7 86 80 00 00 00 00 ac 69 a0 c9 c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 e8 57 d5 b9 df 80 3d 78 86 02 00 00 75 0e 0f 0b eb fe 66 2e 0f 1f 84 00 00 00 00 00 eb fe 66 66 66 66 66 [ 7783.883973] RIP [a0675132] kvm_handle_fault_on_reboot+0x12/0x30 [kvm] [ 7783.883994] RSP 8800735ddbd8 [ 7783.884010] ---[ end trace 89b86beb3c94c6d1 ]--- This is /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping: 2 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl pni
Re: Fix the warnings when compiling kvm user space on 2.6.29
Zhiyong Wu wrote: HI, When compiling the lastest the code for kvm user space on 2.6.29 i386, the following warnings has appeared: test/x86/msr.c:10: warning: \u2018report\u2019 defined but not used test/x86/msr.c:18: warning: \u2018wrmsr\u2019 defined but not used test/x86/msr.c:23: warning: \u2018rdmsr\u2019 defined but not used Please send patches with a signoff, like kernel patches. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network questions on Qemu
zshan wrote: hi all: I am now recently using KVM which use the Qemu to perform network I/O activities, I use the tun/tap bridging to let the guest os connect to the Internet , and the detailed network topology is as follows: Wow, ascii art in an image. And I am so curious about the interaction between the tap and qemu, how can packet been passed from tap to qemu, and what is the ingress path in detail ? Look in qemu/net.c, qemu uses read() and write() to receive and send packets through tap. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Mapping a virtual block device on the guest
The reason I ask this question is because that I don't have any virtio-pci and virtio-blk modules loaded in my guest but still I could access the virtual block device. Thx, Venkat -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Kumar, Venkat Sent: Tuesday, April 07, 2009 3:52 PM To: kvm@vger.kernel.org Subject: Mapping a virtual block device on the guest I understand that the option -drive file=/dev/path/to/host/device,if=virtio would map the device given in the file parameter as a virtual block device on the guest. Can somebody explain me the roles of virtio-pci and virtio-blk modules on the guest in accessing the virtual block device. I am unable to understand the design. Thx, Venkat -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Make kvm_cpu_(has|get)_interrupt() work for userspace irqchip too.
On Tuesday 07 April 2009 17:08:12 Gleb Natapov wrote:
Signed-off-by: Gleb Natapov g...@redhat.com
---
arch/x86/kvm/irq.c | 39 +++
arch/x86/kvm/svm.c | 11 +++
arch/x86/kvm/vmx.c | 18 +-
arch/x86/kvm/x86.c |4 ++--
4 files changed, 41 insertions(+), 31 deletions(-)
diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index cf17ed5..6974e7c 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -24,6 +24,7 @@
#include irq.h
#include i8254.h
+#include x86.h
/*
* check if there are pending timer events
@@ -48,14 +49,17 @@ int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
{
struct kvm_pic *s;
- if (kvm_apic_has_interrupt(v) == -1) { /* LAPIC */
- if (kvm_apic_accept_pic_intr(v)) {
- s = pic_irqchip(v-kvm);/* PIC */
- return s-output;
- } else
- return 0;
+ if (irqchip_in_kernel(v-kvm)) {
+ if (kvm_apic_has_interrupt(v) == -1) { /* LAPIC */
+ if (kvm_apic_accept_pic_intr(v)) {
+ s = pic_irqchip(v-kvm);/* PIC */
+ return s-output;
+ } else
+ return 0;
+ }
+ return 1;
}
- return 1;
+ return v-arch.irq_summary;
}
Use if (!irqchip_in_kernel(v-kvm)) for userspace seems more simple(rather
than a series of indention...).
EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt);
@@ -64,18 +68,21 @@ EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt);
*/
int kvm_cpu_get_interrupt(struct kvm_vcpu *v)
{
- struct kvm_pic *s;
- int vector;
+ if (irqchip_in_kernel(v-kvm)) {
+ struct kvm_pic *s;
+ int vector;
- vector = kvm_get_apic_interrupt(v); /* APIC */
- if (vector == -1) {
- if (kvm_apic_accept_pic_intr(v)) {
- s = pic_irqchip(v-kvm);
- s-output = 0; /* PIC */
- vector = kvm_pic_read_irq(v-kvm);
+ vector = kvm_get_apic_interrupt(v); /* APIC */
+ if (vector == -1) {
+ if (kvm_apic_accept_pic_intr(v)) {
+ s = pic_irqchip(v-kvm);
+ s-output = 0; /* PIC */
+ vector = kvm_pic_read_irq(v-kvm);
+ }
}
+ return vector;
}
- return vector;
+ return kvm_pop_irq(v);
}
EXPORT_SYMBOL_GPL(kvm_cpu_get_interrupt);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 053f3c5..1903c27 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2089,8 +2089,9 @@ static int interrupt_window_interception(struct
vcpu_svm *svm, * If the user space waits to inject interrupts, exit as soon
as * possible
*/
- if (kvm_run-request_interrupt_window
- !svm-vcpu.arch.irq_summary) {
+ if (!irqchip_in_kernel(svm-vcpu.kvm)
+ kvm_run-request_interrupt_window
+ !kvm_cpu_has_interrupt(svm-vcpu)) {
++svm-vcpu.stat.irq_window_exits;
kvm_run-exit_reason = KVM_EXIT_IRQ_WINDOW_OPEN;
return 0;
@@ -2371,7 +2372,8 @@ static void do_interrupt_requests(struct kvm_vcpu
*vcpu, (svm-vmcb-save.rflags X86_EFLAGS_IF)
(svm-vcpu.arch.hflags HF_GIF_MASK));
- if (svm-vcpu.arch.interrupt_window_open svm-vcpu.arch.irq_summary)
+ if (svm-vcpu.arch.interrupt_window_open
+ kvm_cpu_has_interrupt(svm-vcpu))
/*
* If interrupts enabled, and not blocked by sti or mov ss.
Good.
*/
@@ -2381,7 +2383,8 @@ static void do_interrupt_requests(struct kvm_vcpu
*vcpu, * Interrupts blocked. Wait for unblock.
*/
if (!svm-vcpu.arch.interrupt_window_open
- (svm-vcpu.arch.irq_summary || kvm_run-request_interrupt_window))
+ (kvm_cpu_has_interrupt(svm-vcpu) ||
+ kvm_run-request_interrupt_window))
svm_set_vintr(svm);
else
svm_clear_vintr(svm);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c6997c0..b3292c1 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2535,21 +2535,20 @@ static void do_interrupt_requests(struct kvm_vcpu
*vcpu, vmx_inject_nmi(vcpu);
if (vcpu-arch.nmi_pending)
enable_nmi_window(vcpu);
- else if (vcpu-arch.irq_summary
- || kvm_run-request_interrupt_window)
+ else if (kvm_cpu_has_interrupt(vcpu) ||
+ kvm_run-request_interrupt_window)
enable_irq_window(vcpu);
return;
}
if (vcpu-arch.interrupt_window_open) {
- if (vcpu-arch.irq_summary !vcpu-arch.interrupt.pending)
-
Re: The compiling of lastest KVM user space code FAIL on the lastest kernel tree
Zhiyong Wu wrote:
HI,
when compiling kvm user space on the lastest kernel tree,
the compile FAIL; but on 2.6.29, this compile has succeeded.
The version of the lastest kernel tree is
[r...@fedora9 linux-2.6 {master}]$ git describe
v2.6.29-9854-gd508afb
[r...@fedora9 kvm-userspace {master}]$ make
...
rm -f include/asm include-compat/asm
ln -sf asm-x86 include/asm
ln -sf asm-x86 include-compat/asm
make -C /home/zwu/kernel/linux-2.6/ M=`pwd` \
LINUXINCLUDE=-I`pwd`/include -Iinclude \
\
-Iarch/x86/include -I`pwd`/include-compat \
-include include/linux/autoconf.h \
-include `pwd`/x86/external-module-compat.h
make[2]: Entering directory `/home/zwu/kernel/linux-2.6'
CC [M] /home/zwu/virt/kvm-userspace/kernel/x86/svm.o
In file included from /home/zwu/virt/kvm-userspace/kernel/x86/svm.c:57:
/home/zwu/virt/kvm-userspace/kernel/include/linux/kvm_host.h:191:
error: field \u2018mmu_notifier\u2019 has incomplete type
make[4]: *** [/home/zwu/virt/kvm-userspace/kernel/x86/svm.o] Error 1
make[3]: *** [/home/zwu/virt/kvm-userspace/kernel/x86] Error 2
make[2]: *** [_module_/home/zwu/virt/kvm-userspace/kernel] Error 2
make[2]: Leaving directory `/home/zwu/kernel/linux-2.6'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/zwu/virt/kvm-userspace/kernel'
make: *** [kernel] Error 2
It seems that the macro CONFIG_MMU_NOTIFIER is undefined in the
lastest kernel tree.
You need to select CONFIG_KVM in your .config; that will enable
CONFIG_MMU_NOTIFIER.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix crash on resolution change - screen dump - vga redraw
The vga screen dump function updates last_width and last_height, but does not change the DisplaySurface that these variables describe. A consequent vga_draw_graphic() will therefore fail to resize the surface and crash. Fix by invalidating the display state after a screen dump, forcing vga_draw_graphic() to reallocate the DisplaySurface. Signed-off-by: Avi Kivity a...@redhat.com --- hw/vga.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/vga.c b/hw/vga.c index b1e4373..4d1049b 100644 --- a/hw/vga.c +++ b/hw/vga.c @@ -2678,4 +2678,5 @@ static void vga_screen_dump(void *opaque, const char *filename) vga_screen_dump_graphic(s, filename); else vga_screen_dump_text(s, filename); +vga_invalidate_display(s); } -- 1.6.0.6 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
Daniel Veillard wrote:
On Tue, Apr 07, 2009 at 10:10:20AM +0200, Gerd Hoffmann wrote:
Hi,
I'd like to update the VERSION string in QEMU's svn tree. Right now,
it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing.
I don't want to make it 0.11.0 either because that's not going to be
reliable from a feature detection perspective. What I would like is to
make it 0.11.0-devel or something similar to that.
Maybe 0.10.99 ? Or 0.10.90, leaving the door open to number the 0.11
beta / rc versions (if any) 0.10.9{1,2,3}?
Concur, we have no good way of representing something like 0.11.0-devel
from an rpm Name-Version-Release and be sure it won't break down the
road if we change our mind on the final naming scheme, while something
like 0.10.90 convey the intent while still being compatible with the
existing numbering scheme (plus it eventually forces you to release the
new version ;-)
I think that's going to lead to even more confusion. While I'm inclined
to not greatly mind 0.10.99 for the development tree, when we do release
candidates for the next release, it's going to be 0.11.0-rc1. I don't
expect RPMs to ever be created from non-release versions of QEMU
provided we stick to our plan of frequent releases.
I still think libvirt should work with versions of QEMU/KVM built from
svn/git though. I think the only way to do that is for libvirt to relax
their version checks to accommodate suffixes in the form
major.minor.stable-foo.
Regards,
Anthony Liguori
Daniel
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ksm - dynamic page sharing driver for linux v2
On Sat, Apr 04, 2009 at 05:35:18PM +0300, Izik Eidus wrote:
From v1 to v2:
1)Fixed security issue found by Chris Wright:
Ksm was checking if page is a shared page by running !PageAnon.
Beacuse that Ksm scan only anonymous memory, all !PageAnons
inside ksm data strctures are shared page, however there might
be a case for do_wp_page() when the VM_SHARED is used where
do_wp_page() would instead of copying the page into new anonymos
page, would reuse the page, it was fixed by adding check for the
dirty_bit of the virtual addresses pointing into the shared page.
I was not finding any VM code tha would clear the dirty bit from
this virtual address (due to the fact that we allocate the page
using page_alloc() - kernel allocated pages), ~but i still want
confirmation about this from the vm guys - thanks.~
As far as I can tell this wasn't a bug and this change is
unnecessary. I already checked this bit but I may have missed
something, so I ask here to be sure.
As far as I can tell when VM_SHARED is set, no anonymous page can ever
be allocated by in that vma range, hence no KSM page can ever be
generated in that vma either. MAP_SHARED|MAP_ANONYMOUS is only a
different API for /dev/shm, IPCSHM backing, no anonymous pages can
live there. It surely worked like that in older 2.6, reading latest
code it seems to still work like that, but if something has changed
Hugh will surely correct me in a jiffy ;).
I still see this in the file=null path.
} else if (vm_flags VM_SHARED) {
error = shmem_zero_setup(vma);
if (error)
goto free_vma;
}
So you can revert your change for now.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] PCI pass-through fixups
* Sheng Yang (sh...@linux.intel.com) wrote: On Tuesday 07 April 2009 08:02:10 Chris Wright wrote: * Alex Williamson (alex.william...@hp.com) wrote: I'm wondering if we need a spot for device specific fixups for PCI pass-through. In the example below, I want to expose a single port of an Intel 82571EB quad port copper NIC to a guest. It works great until I shutdown the guest, at which point the guest e1000e driver knows by the device ID that the NIC is a quad port, and blindly attempts to twiddle some bits on the bridge above it (that doesn't exist). And what happens? And the output of DEVICE_ASSIGNMENT_DEBUG=1 may help. And I don't have trouble here with another dual/quad port card by Intel, but not 82571EB. Right, it's driver dependent. I too can assign a single port w/out trouble. I'm assuming the guest just complains at rmmod? thanks, -chris -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] PCI pass-through fixups
* Alex Williamson (alex.william...@hp.com) wrote: On Tue, 2009-04-07 at 07:54 -0700, Chris Wright wrote: * Sheng Yang (sh...@linux.intel.com) wrote: On Tuesday 07 April 2009 08:02:10 Chris Wright wrote: * Alex Williamson (alex.william...@hp.com) wrote: I'm wondering if we need a spot for device specific fixups for PCI pass-through. In the example below, I want to expose a single port of an Intel 82571EB quad port copper NIC to a guest. It works great until I shutdown the guest, at which point the guest e1000e driver knows by the device ID that the NIC is a quad port, and blindly attempts to twiddle some bits on the bridge above it (that doesn't exist). And what happens? And the output of DEVICE_ASSIGNMENT_DEBUG=1 may help. And I don't have trouble here with another dual/quad port card by Intel, but not 82571EB. Right, it's driver dependent. I too can assign a single port w/out trouble. I'm assuming the guest just complains at rmmod? No, it's a little more severe than that, see below. This may be rather unique, I certainly wasn't expecting different device IDs for a quad port versus a single port. However, you can see in e1000e/82571.c:e1000_get_variants_82571() we set a flag for quad port device IDs, apparently for WOL only being supported on the first port. Then when we shutdown, we hit e1000e/netdev.c:e1000_suspend() where we take that quad port flag and blindly walk up to bus-self, which is NULL, and try to get the PCI capabilities on it. That's a form of guest complaint ;-) Yes, I noticed the global wol bit, but didn't see the bus-self...ick It may be prudent for the driver to check the pointer, but there's probably also an argument that the device ID indicates something about the topology that makes that unnecessary, so we may hit the same problem in drivers we don't have source for. I agree that my rough sketch of a patch is pretty fragile and static. Maybe an option to override a device ID on the command line would be more flexible. Something like: -pcidevice host=09:00.0,device_id=0x105E This puts the burden on the user, but at least allows us an out. Still ugly, esp since there's no real way to know ahead of time -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] [PATCH 13/16] kvm: enable MSI-X capabilty for assigned device
On Tue, 2009-04-07 at 14:09 +0800, Sheng Yang wrote: On Saturday 04 April 2009 05:27:43 Alex Williamson wrote: Do we need some disable logic here? If I toggle a bnx2 NIC in a guest, I get the following when it attempts to come back up: MSI-X entry number is zero! assigned_dev_update_msix_mmio: No such device or address It seems that driver didn't fill the MMIO with any correct MSIX information, or the program fail to intercept it after driver set enable bit of MSIX. It's strange... (Have it got something to do with PM and some EXP feature you mentioned?) My guess was that it filled in the MSIX info, but then can't find a free slot to reload the MSIX data when it tries to re-enable MSIX. I hacked the bnx2 driver to not rely on PM and EXP capabilities for this test, it seems to work, but it's possible that I broke something. My host also locks up the second time I try to export this device to a guest, maybe a problem with my bnx2 hacks, MSIX not getting reset, or prototype hardware. I'll see if I can find another MSIX capable device to export to a guest. Could you enable DEVICE_ASSSIGNMENT_DEBUG=1 in qemu/hw/device-assignment.c and post the output? Yup, see below. The error comes after I 'ifdown eth0; ifup eth0' in the guest. Note bnx2 appears to only turn on MSIX for SMP systems. Thanks, Alex $ sudo qemu-system-x86_64 -hda kvm-vtd.img -m 4096 -net none -vnc :1 -pcidevice host=03:00.0 -boot c -smp 8 init_assigned_device: Registering real physical device 03:00.0 (bus=3 dev=0 func=0) get_real_device: region 0 size 33554432 start 0xf400 type 512 resource_fd 19 assigned_dev_pci_read_config: (4.0): address= val=0x14e4 len=2 assigned_dev_pci_read_config: (4.0): address=0002 val=0x1639 len=2 assigned_dev_pci_read_config: (4.0): address= val=0x14e4 len=2 assigned_dev_pci_read_config: (4.0): address=0002 val=0x1639 len=2 assigned_dev_pci_read_config: (4.0): address= val=0x14e4 len=2 assigned_dev_pci_read_config: (4.0): address=0002 val=0x1639 len=2 assigned_dev_pci_read_config: (4.0): address=000a val=0x0200 len=2 assigned_dev_pci_read_config: (4.0): address= val=0x14e4 len=2 assigned_dev_pci_read_config: (4.0): address=0002 val=0x1639 len=2 assigned_dev_pci_write_config: (4.0): address=0010 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0010 val=0xfe00 len=4 assigned_dev_pci_read_config: (4.0): address=0010 val=0xfe00 len=4 assigned_dev_pci_write_config: (4.0): address=0010 val=0xf400 len=4 assigned_dev_iomem_map: e_phys=f400 r_virt=0x7f14f4ba type=0 len=0200 region_num=0 assigned_dev_iomem_map: munmap done, virt_base 0x0x7f14f4bac000 assigned_dev_pci_read_config: (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_write_config: (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_write_config: NON BAR (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_write_config: (4.0): address=0014 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0014 val=0x len=4 assigned_dev_pci_write_config: (4.0): address=0018 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0018 val=0x len=4 assigned_dev_pci_write_config: (4.0): address=001c val=0x len=4 assigned_dev_pci_read_config: (4.0): address=001c val=0x len=4 assigned_dev_pci_write_config: (4.0): address=0020 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0020 val=0x len=4 assigned_dev_pci_write_config: (4.0): address=0024 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0024 val=0x len=4 assigned_dev_pci_write_config: (4.0): address=0030 val=0x len=4 assigned_dev_pci_write_config: NON BAR (4.0): address=0030 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0030 val=0x0001 len=4 assigned_dev_pci_read_config: (4.0): address=0030 val=0x0001 len=4 assigned_dev_pci_write_config: (4.0): address=0030 val=0x0001 len=4 assigned_dev_pci_write_config: NON BAR (4.0): address=0030 val=0x0001 len=4 assigned_dev_pci_read_config: (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_write_config: (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_write_config: NON BAR (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_read_config: (4.0): address=003d val=0x0001 len=1 assigned_dev_pci_write_config: (4.0): address=003c val=0x000b len=1 assigned_dev_pci_read_config: (4.0): address=000a val=0x0200 len=2 assigned_dev_pci_read_config: (4.0): address= val=0x14e4 len=2 assigned_dev_pci_read_config: (4.0): address=0002 val=0x1639 len=2 assigned_dev_pci_read_config: (4.0): address=000e val=0x0080 len=1 assigned_dev_pci_read_config: (4.0): address= val=0x163914e4 len=4 assigned_dev_pci_read_config: (4.0): address=000e val=0x0080 len=1 assigned_dev_pci_read_config: (4.0): address=0006 val=0x0010 len=2 assigned_dev_pci_read_config: (4.0):
Re: [PATCH] KVM: Make kvm header compile under g++.
No, I just missed your patch. Applied now. Thanks for pestering, it's the right thing when I miss something (copying me also helps). Thanks. btw, can you share what you're doing with kvm and g++? I am a researcher at HP Labs studying system architecture. For many years, I have been involved in a simulator project called M5 (m5sim.org). It shares a lot of things in common with qemu/kvm, except instead of performance as our number one goal, measurement is our number one goal. We model many aspects of computer systems in detail trying to understand how to build future systems. We support a number of architectures and are right now trying to finish x86 support. We want M5 to be able to do everything x86 by itself, but I was looking into the feasibility of using KVM as a fast CPU model to help us get workloads running at an interesting point quickly at which point we can switch over to a more detailed CPU model. Since M5 does all of the modeling of memory, devices, and interrupts itself, this really would use just the KVM bits and not use QEMU. We can also use KVM in a single stepping mode to validate the correctness of the simulator itself. My initial playing around with the code looks pretty promising. The only big question mark I have is how to deal with time. I really need the simulator to control what the VCPU understands as the passage of time (think about exactly when interrupts arrive, or exactly how VCPUs advance with respect to each other when they're communicating through shared memory). This has to be done to properly warm up the system. I'm not concerned about whether I can do it at all. I just want to make sure that I maintain the speed of KVM while I do it. Anyway, thanks for your hard work! Nate -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: AW: KVM performance
Hello, I think that I've mixed the values in my first email for this topic and actually provided the values without network virtio enabled. So the values for a kvm vmu with enabled virtio are indeed a little better but not as good as Xen. At the moment I'm still working to get the virtio disk vmu setup working as I think it would be interesting how the performance values would improve. All following tests have been executed using a vmu (ram 512 mb, 1 core 2,2 GHz) and the vlc (video player, that can f.e. stream, receive, transcode videos) VMU setup for first performance values (without network virtio) /usr/bin/qemu-kvm -boot c -hda /images/vmu01.raw -m 512 -net nic,vlan=0,macaddr=aa:bb:cc:dd:ee:10 -net tap,ifname=tap0,vlan=0,script=/etc/kvm/qemu-ifup,downscript=/etc/kvm/qemu-ifdown -net nic,vlan=1,macaddr=aa:bb:cc:dd:ee:11 -net tap,ifname=tap1,vlan=1,script=/etc/kvm/qemu-ifup,downscript=/etc/kvm/qemu-ifdown -vnc 127.0.0.1:2 -k de --daemonize VMU setup for second performance values (with network virtio) /usr/bin/qemu-kvm -boot c -hda /images/vmu01.raw -m 512 -net nic,vlan=0,macaddr=aa:bb:cc:dd:ee:10,model=virtio -net tap,ifname=tap0,vlan=0,script=/etc/kvm/qemu-ifup,downscript=/etc/kvm/qemu-ifdown -net nic,vlan=1,macaddr=aa:bb:cc:dd:ee:11,model=virtio -net tap,ifname=tap1,vlan=1,script=/etc/kvm/qemu-ifup,downscript=/etc/kvm/qemu-ifdown -vnc 127.0.0.1:2 -k de --daemonize The first column of performance values show the VMU without virtio network, the second column with virtio network 1. Subtest: VLC reads video from local disk and streams it via udp to another pc Host performance: 11% 11% kvm process in host (top): 22% 22% vlc process in vmu (top): 15% 7% 2. Subtest: Just receiving a video via udp (no displaying as no X11 is installed on the vmu) Host performance: 16% 10% kvm process in host (top) : 30% 17% vlc process in vmu (top) : 3% 3% 3. Subtest: Receiving a video via udp and saving it locally in a file Host performance: 17% 11% kvm process in host (top) : 38% 24% vlc process in vmu (top) : 12% 11% 4. Subtest: Reading video locally, adding a logo to the video stream and then saving the video locally Host performance: 50% 50% kvm process in host (top) : 99% 99% vlc process in vmu (top) : 99% 99% 5. Subtest: Receiving the video from pc 1 and at the same time streaming the received video to pc 2 Host performance: 23% 18% kvm process in host (top) : 22% 35% vlc process in vmu (top) : 48% 10% 6. The originial test: receiving streamed video, adding a logo and the sending it to another pc Host performance: 52% 50% kvm process in host (top) : 77-99% 60-99% (for both most time 99%) vlc process in vmu (top) : 80-99% 50-99% (for both most time 99%) I've have repeated almost all tests with XEN 1. Subtest: VLC reads video from local disk and streams it via udp to another pc Host performance (Domain-0 + vmu)(virt-manager):4% VMU (virt-manager) : 2% vlc process in vmu (top) : 1% 3. Subtest: Receiving a video via udp and saving it locally in a file Host performance (Domain-0 + vmu)(virt-manager):7% VMU (virt-manager) : 4% vlc process in vmu (top) : 3% 4. Subtest: Reading video locally, adding a logo to the video stream and then saving the video locally Host performance (Domain-0 + vmu)(virt-manager):3-55% VMU (virt-manager) : 0-50% vlc process in vmu (top) : 14 -99% varies a lot 5. Subtest: Receiving the video from pc 1 and at the same time streaming the received video to pc 2 Host performance (Domain-0 + vmu)(virt-manager):6% VMU (virt-manager) : 3% vlc process in vmu (top) : 1% 6. The originial test: receiving streamed video, adding a logo and the sending it to another pc Host performance (Domain-0 + vmu)(virt-manager):23% VMU (virt-manager) :
Re: [PATCH] KVM: Make kvm header compile under g++.
nathan binkert wrote: btw, can you share what you're doing with kvm and g++? I am a researcher at HP Labs studying system architecture. For many years, I have been involved in a simulator project called M5 (m5sim.org). It shares a lot of things in common with qemu/kvm, except instead of performance as our number one goal, measurement is our number one goal. We model many aspects of computer systems in detail trying to understand how to build future systems. We support a number of architectures and are right now trying to finish x86 support. We want M5 to be able to do everything x86 by itself, but I was looking into the feasibility of using KVM as a fast CPU model to help us get workloads running at an interesting point quickly at which point we can switch over to a more detailed CPU model. Since M5 does all of the modeling of memory, devices, and interrupts itself, this really would use just the KVM bits and not use QEMU. We can also use KVM in a single stepping mode to validate the correctness of the simulator itself. Excellent. One of the things I'm trying hard to do is keep kvm from being a 'qemu accelerator' and generally useful for other projects. That is, I'm trying to keep the userspace interface neutral, and not to model exactly the hardware qemu provides but allow for other configurations. One example where we failed to do this is in mapping interrupts, where PIC IRQ line n was tied to IOAPIC INTI line n. This came back to bite us when qemu changed its model. So if you notice such issues in kvm please bring them up so we can fix them. My initial playing around with the code looks pretty promising. The only big question mark I have is how to deal with time. I really need the simulator to control what the VCPU understands as the passage of time (think about exactly when interrupts arrive, or exactly how VCPUs advance with respect to each other when they're communicating through shared memory). This has to be done to properly warm up the system. I'm not concerned about whether I can do it at all. I just want to make sure that I maintain the speed of KVM while I do it. If you're interested in determinism, can't you just warm up the system once and then save the state? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
Anthony Liguori wrote: I still think libvirt should work with versions of QEMU/KVM built from svn/git though. I think the only way to do that is for libvirt to relax their version checks to accommodate suffixes in the form major.minor.stable-foo. Ok, but try to stick to a well-defined rule about what suffix means later or earlier. In package managers, 1.2.3-rc1 is typically seen as a later version than 1.2.3 purely due to syntax. If you're consistently meaning 0.11.0-rc1 is earlier than 0.11.0 (final), that might need to be encoded in libvirt and other wrappers, if they have any fine-grained version sensistivity such as command line changes or bug workarounds. The Linux kernel was guilty of mixing up later and earlier version suffixes like this. With Linux this is a bit more important because it changes a lot between versions, so some apps do need fine-grained version checks to workaround bugs or avoid buggy features. Maybe that won't even happen with QEMU and libvirt working together. -- Jamie -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kvm crash when I create a Guest
On Tue, Apr 7, 2009 at 2:15 AM, Alessio Rocchi alessio.roc...@staff.dada.net wrote: I'm Running Ubuntu 8.10, here is the command I use: kvm -net none -m 192 -no-acpi -hda ./gentoo_cleanvm.img.tar.lzma Ubuntu 8.10 uses kvm-72 by default. You might, perhaps, try kvm-84, which is more current and fixes a number of issues. You can try the pre-built packages available for Ubuntu 8.10 at: * https://launchpad.net/~ubuntu-virt/+archive/ppa You should install both the kvm and the kvm-source package, which would get you kvm-84 userspace and the kernel module. :-Dustin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Make kvm header compile under g++.
Excellent. One of the things I'm trying hard to do is keep kvm from being a 'qemu accelerator' and generally useful for other projects. That is, I'm trying to keep the userspace interface neutral, and not to model exactly the hardware qemu provides but allow for other configurations. One example where we failed to do this is in mapping interrupts, where PIC IRQ line n was tied to IOAPIC INTI line n. This came back to bite us when qemu changed its model. So if you notice such issues in kvm please bring them up so we can fix them. I certainly will, and I have noticed such things already. They're mostly problems for me in libkvm at this point. I haven't noticed any big problems with KVM itself yet. I'm going back and forth as to whether or not I want to use libkvm at all, though if you're receptive to changes to that interface, I'll definitely keep that in mind. On the other hand, since I'm using C++, I may just write a C++ libkvm and try to give it to you guys. I will try to work with the existing libkvm for now though. If you're interested in determinism, can't you just warm up the system once and then save the state? We often do stuff like that. We drop checkpoints and run from the checkpoints, but the problem with that is that we often change things in such a way that you need to boot fresh again. If we change a device model or the kernel there's no getting around it. There are more subtle things though. For example, if you warm up a simulation with a simulated Gigabit ethernet and then decide that you really wanted 10 Gig, you can't just change it when you resume the checkpoint because TCP takes a while to warm up. We could of course warm up further from the checkpoint, but if you were to go in the reverse direction 10G - 1G, TCP starts dropping packets and it takes a long time in a simulator to deal with that. If I can impose a good enough notion of time, I can deal with those things. Determinism is another issue altogether. Our simulator is deterministic, and we'd love to keep that property, but that's even more difficult, unless we can figure out a way to tell KVM to do something like execute up to 100 instructions right now. I'm pretty far from really worrying about these problems. I do have lots of ideas and I know that there are a bunch of papers out there that work on this sort of thing. Thanks again, Nate -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AW: AW: KVM performance
BRAUN, Stefanie wrote: 1. Subtest: VLC reads video from local disk and streams it via udp to another pc Host performance: 11% 11% kvm process in host (top): 22% 22% vlc process in vmu (top): 15% 7% While this isn't wonderful, it's not your major bottleneck now. What's the bandwidth generated by the workload? 4. Subtest: Reading video locally, adding a logo to the video stream and then saving the video locally Host performance: 50% 50% kvm process in host (top) : 99% 99% vlc process in vmu (top) : 99% 99% Now this is bad. Please provide the output of 'kvm_stat -1' while this is running. Also, describe the guest. Is it Linux? if so, i386 or x86_64? and is CONFIG_HIGHMEM enabled? UDP performance is a known issue now, and we are working on it. TCP is much better due to segmentation offload. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] Re: [PATCH 1/2] qemu: Allow SMBIOS entries to be loaded and provided to the VM BIOS
On Mon, 2009-04-06 at 17:42 -0500, Anthony Liguori wrote:
Alex Williamson wrote:
Hi Anthony,
On Mon, 2009-04-06 at 14:50 -0500, Anthony Liguori wrote:
Alex Williamson wrote:
I know we have to support blobs because of OEM specific smbios entries,
but there are a number of common ones that it would probably be good to
specify in a less user-unfriendly way. What do you think?
Yeah, I'll admit this is a pretty unfriendly interface. I get from your
comment on the other part of the patch that you'd prefer not to get into
the mess of having both binary blobs and command line switches
augmenting the blobs. This seems reasonable, but also means that we
need a way to fully define the tables we generate from the command line.
For a type 0 entry, that might mean the following set of switches:
-bios-version, -bios-date, -bios-characteristics, -bios-release
You could go one level higher:
-smbios type=0,bios-version='1.0',bios-date='2009/10/20' etc.
That helps, but we have the same complexity in getting the data into the
the bios. Adding a new QEMU_CFG_* for each field in every table we want
to specify seems excessive. I'm half tempted to generate all the smbios
entries in qemu and push them through a port to the bios. That would
leave a lot of duplicate code in bochs though. Maybe the bios could
read a stream of these through the port:
uint16_t length;
uint8_t type; /* 0: field, 1: table */
union {
struct {
uint8_t type; /* smbios entry type */
uint8_t offset;
uint8_t data[];
} field;
struct {
uint8_t data[]; /* binary blob */
} table;
} entry;
We could convert uuid to use this too. The bios doesn't have a very
effective means to seek through these, but maybe its not an issue as
long as these entries are sparsely used. We could also use the table
generation to enforce mutual exclusion between specifying fields and
tables to avoid the uuid issue in the previous set. Other ideas?
Thanks,
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] Re: [PATCH 1/2] qemu: Allow SMBIOS entries to be loaded and provided to the VM BIOS
Alex Williamson wrote:
On Mon, 2009-04-06 at 17:42 -0500, Anthony Liguori wrote:
That helps, but we have the same complexity in getting the data into the
the bios. Adding a new QEMU_CFG_* for each field in every table we want
to specify seems excessive.
Right.
I'm half tempted to generate all the smbios
entries in qemu and push them through a port to the bios. That would
leave a lot of duplicate code in bochs though. Maybe the bios could
read a stream of these through the port:
uint16_t length;
uint8_t type; /* 0: field, 1: table */
union {
struct {
uint8_t type; /* smbios entry type */
uint8_t offset;
uint8_t data[];
} field;
struct {
uint8_t data[]; /* binary blob */
} table;
} entry;
We could convert uuid to use this too.
Yes, this is what I was leaning toward too.
The bios doesn't have a very
effective means to seek through these, but maybe its not an issue as
long as these entries are sparsely used. We could also use the table
generation to enforce mutual exclusion between specifying fields and
tables to avoid the uuid issue in the previous set. Other ideas?
I'm pretty happy with this. The argument against it is that if we pass
higher level information down via the FW interface, other types of FW
(like OpenBIOS) could also use that information in a meaningful way.
The problem is, beyond things like UUID, you start to get into pretty
specific stuff and I'm not convinced it would all generalize very well.
OEM tables are also impossible to represent this way.
So yeah, plumbing the tables directly through to the BIOS seems to make
sense to me.
Thanks,
Alex
--
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] The included file stropts.h does not exist in the source tree, so this line should be deleted.
Signed-off-by: Zhiyong Wu zwu.ker...@gmail.com --- libkvm/libkvm-x86.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c index dcef548..2fc4fce 100644 --- a/libkvm/libkvm-x86.c +++ b/libkvm/libkvm-x86.c @@ -4,7 +4,6 @@ #include sys/ioctl.h #include string.h #include unistd.h -#include stropts.h #include sys/mman.h #include stdio.h #include errno.h -- 1.6.2.2.446.gfbdc0 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
On Tue, Apr 07, 2009 at 08:52:46AM -0500, Anthony Liguori wrote: I think that's going to lead to even more confusion. While I'm inclined to not greatly mind 0.10.99 for the development tree, when we do release candidates for the next release, it's going to be 0.11.0-rc1. I don't expect RPMs to ever be created from non-release versions of QEMU provided we stick to our plan of frequent releases. FWIW, GDB uses 6.8.50 (devel branch), 6.8.90 (release branch), 6.8.91 (rc1). That's worked out well for us. -- Daniel Jacobowitz CodeSourcery -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cancel the warning in msr.c
From: zwu zwu.ker...@gmail.com
Signed-off-by: zwu zwu.ker...@gmail.com
---
user/test/x86/msr.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/user/test/x86/msr.c b/user/test/x86/msr.c
index 5010ad0..92102fa 100644
--- a/user/test/x86/msr.c
+++ b/user/test/x86/msr.c
@@ -6,6 +6,7 @@
int nr_passed, nr_tests;
+#ifdef __x86_64__
static void report(const char *name, int passed)
{
++nr_tests;
@@ -27,6 +28,7 @@ static unsigned long long rdmsr(unsigned index)
return value;
}
+#endif
static void test_kernel_gs_base(void)
{
--
1.5.4.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix crash on resolution change - screen dump - vga redraw
Avi Kivity wrote: The vga screen dump function updates last_width and last_height, but does not change the DisplaySurface that these variables describe. A consequent vga_draw_graphic() will therefore fail to resize the surface and crash. Fix by invalidating the display state after a screen dump, forcing vga_draw_graphic() to reallocate the DisplaySurface. Signed-off-by: Avi Kivity a...@redhat.com Applied. Thanks. Regards, Anthony Liguori --- hw/vga.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/vga.c b/hw/vga.c index b1e4373..4d1049b 100644 --- a/hw/vga.c +++ b/hw/vga.c @@ -2678,4 +2678,5 @@ static void vga_screen_dump(void *opaque, const char *filename) vga_screen_dump_graphic(s, filename); else vga_screen_dump_text(s, filename); +vga_invalidate_display(s); } -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Differences in emulation between kvm and kvm -no-kvm
On Tuesday, 7. april 2009 at 21:59 +0200, Milan Plzik wrote: Hello, I somehow managed to produce code which behaves slightly differently when using software emulation and when using kvm. As fas as I know, the bug should be related to reading cursor position from VGA registers. Basically, the bug should be reproducible by executing: #define VGA_CURSOR_LOC_HIGH 0xe #define VGA_CURSOR_LOC_LOW 0xf priv.addr = 0x3d4; priv.data = 0x3d5; outb (priv.addr, VGA_CURSOR_LOC_HIGH); /* Cursor location high */ priv.cursor = inb (priv.data) 8; outb (priv.addr, VGA_CURSOR_LOC_LOW); /* Cursor location low */ priv.cursor += inb (priv.data); This is wrong; looks like the problem was in the end in improperly set %esp register. Anyway, the problem is still the same -- kvm without -no-kvm properly handled stack operations which shouldn't be possible... . But sorry for sending incomplete info I put a testcase at http://stashbox.org/manage_file/480477/kvm-bug.tar.gz . It's my school project, so it's a bit more complicated; if neccessary, I can supply the sources. In kvm -no-kvm it should cause reboot, in plain kvm it should print few colored 'A's into the left upper corner of the screen (rest of the code in binary is unreachable). It uses a bit more complicated setup -- pxegrub2 and tftp loading, but that should not matter -- run.sh should execute kvm with proper arguments, when executed from the kvm-bug directory. Best regards, Milan P.S: Please Cc: me as I'm not subscribed to the list; when possible, I'll be also idling at #kvm (nickname 'mmp'). -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/3] Make rt_down_read_trylock() behave like down_read_trylock()
This patch removes the stupid Read locks within the self-held write lock
succeed behaviour. This is breaking in mm_take_all_locks() since it is quite
common to ensure that a lock is taken with
BUG_ON(down_read_trylock(mm-mmap_sem)).
Signed-off-by: Jan Blunck jblu...@suse.de
---
kernel/rt.c | 12
1 file changed, 12 deletions(-)
Index: b/kernel/rt.c
===
--- a/kernel/rt.c
+++ b/kernel/rt.c
@@ -381,18 +381,6 @@ int rt_down_read_trylock(struct rw_sema
unsigned long flags;
int ret;
- /*
-* Read locks within the self-held write lock succeed.
-*/
- spin_lock_irqsave(rwsem-lock.wait_lock, flags);
- if (rt_mutex_real_owner(rwsem-lock) == current) {
- spin_unlock_irqrestore(rwsem-lock.wait_lock, flags);
- rwsem_acquire_read(rwsem-dep_map, 0, 1, _RET_IP_);
- rwsem-read_depth++;
- return 1;
- }
- spin_unlock_irqrestore(rwsem-lock.wait_lock, flags);
-
ret = rt_mutex_trylock(rwsem-lock);
if (ret)
rwsem_acquire(rwsem-dep_map, 0, 1, _RET_IP_);
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/3] kvm: wake up waitqueue before calling get_cpu()
This moves the get_cpu() call down to be called after we wake up the
waiters. Therefore the waitqueue locks can savely be rt mutex.
Signed-off-by: Jan Blunck jblu...@suse.de
Signed-off-by: Sven-Thorsten Dietrich s...@thebigcorporation.com
---
arch/x86/kvm/x86.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: b/arch/x86/kvm/x86.c
===
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4229,7 +4229,7 @@ static void vcpu_kick_intr(void *info)
void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
{
int ipi_pcpu = vcpu-cpu;
- int cpu = get_cpu();
+ int cpu;
if (waitqueue_active(vcpu-wq)) {
wake_up_interruptible(vcpu-wq);
@@ -4239,6 +4239,7 @@ void kvm_vcpu_kick(struct kvm_vcpu *vcpu
* We may be called synchronously with irqs disabled in guest mode,
* So need not to call smp_call_function_single() in that case.
*/
+ cpu = get_cpu();
if (vcpu-guest_mode vcpu-cpu != cpu)
smp_call_function_single(ipi_pcpu, vcpu_kick_intr, vcpu, 0);
put_cpu();
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/3] Patches for KVM RT
Here are some patches that are necessary to get KVM running with the -rt4 patchset. Cheers, Jan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange guest slowness after some time
On Tuesday 07 April 2009 00:49:17 Tomasz Chmielewski wrote: Tomasz Chmielewski schrieb: As I mentioned, it was using virtio net. Guests running with e1000 (and virtio_blk) don't have this problem. Also, virtio_console seem to be affected by this slowness issue. I'm pretty sure this is different. Older virtio_console code ignored interrupts and polled, and use a heuristic to back off on polling (this was because we used the generic hvc infrastructure which hacked support). You'll find a delay on the first keystroke after idle, but none on the second. Hope that helps, Rusty. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The compiling of lastest KVM user space code FAIL on the lastest kernel tree
HI, avi,
The issue is resolved successfully. Thanks for your direction.
Cheers,
Zhiyong Wu
On Tue, Apr 7, 2009 at 6:47 PM, Avi Kivity a...@redhat.com wrote:
Zhiyong Wu wrote:
HI,
when compiling kvm user space on the lastest kernel tree,
the compile FAIL; but on 2.6.29, this compile has succeeded.
The version of the lastest kernel tree is
[r...@fedora9 linux-2.6 {master}]$ git describe
v2.6.29-9854-gd508afb
[r...@fedora9 kvm-userspace {master}]$ make
...
rm -f include/asm include-compat/asm
ln -sf asm-x86 include/asm
ln -sf asm-x86 include-compat/asm
make -C /home/zwu/kernel/linux-2.6/ M=`pwd` \
LINUXINCLUDE=-I`pwd`/include -Iinclude \
\
-Iarch/x86/include -I`pwd`/include-compat \
-include include/linux/autoconf.h \
-include `pwd`/x86/external-module-compat.h
make[2]: Entering directory `/home/zwu/kernel/linux-2.6'
CC [M] /home/zwu/virt/kvm-userspace/kernel/x86/svm.o
In file included from /home/zwu/virt/kvm-userspace/kernel/x86/svm.c:57:
/home/zwu/virt/kvm-userspace/kernel/include/linux/kvm_host.h:191:
error: field \u2018mmu_notifier\u2019 has incomplete type
make[4]: *** [/home/zwu/virt/kvm-userspace/kernel/x86/svm.o] Error 1
make[3]: *** [/home/zwu/virt/kvm-userspace/kernel/x86] Error 2
make[2]: *** [_module_/home/zwu/virt/kvm-userspace/kernel] Error 2
make[2]: Leaving directory `/home/zwu/kernel/linux-2.6'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/zwu/virt/kvm-userspace/kernel'
make: *** [kernel] Error 2
It seems that the macro CONFIG_MMU_NOTIFIER is undefined in the
lastest kernel tree.
You need to select CONFIG_KVM in your .config; that will enable
CONFIG_MMU_NOTIFIER.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATH 1/2] kvm userspace: Add handler_8/9/10 support to monitor
This is needed by MCE simulation. Signed-off-by: Huang Ying ying.hu...@intel.com --- qemu/monitor.c | 24 1 file changed, 24 insertions(+) --- a/qemu/monitor.c +++ b/qemu/monitor.c @@ -2513,6 +2513,15 @@ static void monitor_handle_command(Monit void *arg3, void *arg4, void *arg5); void (*handler_7)(Monitor *mon, void *arg0, void *arg1, void *arg2, void *arg3, void *arg4, void *arg5, void *arg6); +void (*handler_8)(Monitor *mon, void *arg0, void *arg1, void *arg2, + void *arg3, void *arg4, void *arg5, void *arg6, + void *arg7); +void (*handler_9)(Monitor *mon, void *arg0, void *arg1, void *arg2, + void *arg3, void *arg4, void *arg5, void *arg6, + void *arg7, void *arg8); +void (*handler_10)(Monitor *mon, void *arg0, void *arg1, void *arg2, + void *arg3, void *arg4, void *arg5, void *arg6, + void *arg7, void *arg8, void *arg9); #ifdef DEBUG monitor_printf(mon, command='%s'\n, cmdline); @@ -2810,6 +2819,21 @@ static void monitor_handle_command(Monit handler_7(mon, args[0], args[1], args[2], args[3], args[4], args[5], args[6]); break; +case 8: +handler_8 = cmd-handler; +handler_8(mon, args[0], args[1], args[2], args[3], args[4], args[5], + args[6], args[7]); +break; +case 9: +handler_9 = cmd-handler; +handler_9(mon, args[0], args[1], args[2], args[3], args[4], args[5], + args[6], args[7], args[8]); +break; +case 10: +handler_10 = cmd-handler; +handler_10(mon, args[0], args[1], args[2], args[3], args[4], args[5], + args[6], args[7], args[8], args[9]); +break; default: monitor_printf(mon, unsupported number of arguments: %d\n, nb_args); goto fail; signature.asc Description: This is a digitally signed message part
Re: [kvm] [PATCH 13/16] kvm: enable MSI-X capabilty for assigned device
On Wednesday 08 April 2009 00:38:10 Alex Williamson wrote: On Tue, 2009-04-07 at 14:09 +0800, Sheng Yang wrote: On Saturday 04 April 2009 05:27:43 Alex Williamson wrote: Do we need some disable logic here? If I toggle a bnx2 NIC in a guest, I get the following when it attempts to come back up: MSI-X entry number is zero! assigned_dev_update_msix_mmio: No such device or address It seems that driver didn't fill the MMIO with any correct MSIX information, or the program fail to intercept it after driver set enable bit of MSIX. It's strange... (Have it got something to do with PM and some EXP feature you mentioned?) My guess was that it filled in the MSIX info, but then can't find a free slot to reload the MSIX data when it tries to re-enable MSIX. I hacked the bnx2 driver to not rely on PM and EXP capabilities for this test, it seems to work, but it's possible that I broke something. My host also locks up the second time I try to export this device to a guest, maybe a problem with my bnx2 hacks, MSIX not getting reset, or prototype hardware. I'll see if I can find another MSIX capable device to export to a guest. Could you enable DEVICE_ASSSIGNMENT_DEBUG=1 in qemu/hw/device-assignment.c and post the output? Yup, see below. The error comes after I 'ifdown eth0; ifup eth0' in the guest. Note bnx2 appears to only turn on MSIX for SMP systems. Thanks, Alex Seems your ifdown/ifup script reload the module? Oh god, I found one bug after checked the spec: System software reads this field to determine the MSI-X Table Size *N*, which is encoded as *N-1*. For example, a returned value of “011” indicates a table size of 4. But it seems still can't explain the problem...(OK, it may affect the guest in a unknown way as well...) I would post a fix for it soon. val=0x0008 len=2 assigned_dev_pci_write_config: (4.0): address=0052 val=0x0008 len=2 assigned_dev_pci_read_config: (4.0): address=0006 val=0x0010 len=2 assigned_dev_pci_read_config: (4.0): address=0034 val=0x0040 len=1 assigned_dev_pci_read_config: (4.0): address=0040 val=0x0005 len=1 assigned_dev_pci_read_config: (4.0): address=0041 val=0x0050 len=1 assigned_dev_pci_read_config: (4.0): address=0050 val=0x0011 len=1 assigned_dev_pci_read_config: (4.0): address=0052 val=0x0008 len=2 assigned_dev_pci_read_config: (4.0): address=0054 val=0xc000 len=4 msix_mmio_writel: write to MSI-X entry table mmio offset 0x0, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table mmio offset 0x4, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio offset 0x8, val 0x4191 msix_mmio_writel: write to MSI-X entry table mmio offset 0x10, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table mmio offset 0x14, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio offset 0x18, val 0x4199 msix_mmio_writel: write to MSI-X entry table mmio offset 0x20, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table mmio offset 0x24, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio offset 0x28, val 0x41a1 msix_mmio_writel: write to MSI-X entry table mmio offset 0x30, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table mmio offset 0x34, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio offset 0x38, val 0x41a9 msix_mmio_writel: write to MSI-X entry table mmio offset 0x40, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table mmio offset 0x44, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio offset 0x48, val 0x41b1 msix_mmio_writel: write to MSI-X entry table mmio offset 0x50, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table mmio offset 0x54, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio offset 0x58, val 0x41b9 msix_mmio_writel: write to MSI-X entry table mmio offset 0x60, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table mmio offset 0x64, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio offset 0x68, val 0x41c1 msix_mmio_writel: write to MSI-X entry table mmio offset 0x70, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table mmio offset 0x74, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio offset 0x78, val 0x41c9 msix_mmio_writel: write to MSI-X entry table mmio offset 0x80, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table mmio offset 0x84, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio offset 0x88, val 0x41d1 assigned_dev_pci_read_config: (4.0): address=0004 val=0x0046 len=2 assigned_dev_pci_write_config: (4.0): address=0004 val=0x0446 len=2 assigned_dev_pci_write_config: NON BAR (4.0): The writing to MMIO have been intercepted, but code fail to count it? Strange... Could you try this debug? diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c index 09e54ae..ba31bed 100644 --- a/qemu/hw/device-assignment.c +++ b/qemu/hw/device-assignment.c @@ -45,7 +45,7 @@ #define IORESOURCE_DMA
[PATCH] kvm: Fix wrong counting of MSI-X table size
The PCI spec said...
System software reads this field to determine the MSI-X Table Size *N*,
which is encoded as *N-1*. For example, a returned value of “011”
indicates a table size of 4.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
qemu/hw/device-assignment.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
index 09e54ae..f33ce3c 100644
--- a/qemu/hw/device-assignment.c
+++ b/qemu/hw/device-assignment.c
@@ -818,6 +818,7 @@ static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev)
entries_max_nr = pci_dev-config[pos + 2];
entries_max_nr = PCI_MSIX_TABSIZE;
+entries_max_nr += 1;
/* Get the usable entry number for allocating */
for (i = 0; i entries_max_nr; i++) {
--
1.5.4.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] do not keep interrupt window closed by sti in real mode
While in real mode, sti does not block interrupts from the subsequent
instruction. This is stated at Intel SDM Volume 2b, page 4-432
Without this patch, I cannot boot gpxe option roms at vmx machines.
This is described at https://bugzilla.redhat.com/show_bug.cgi?id=494469
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/vmx.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c6997c0..51e0b8a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2490,18 +2490,19 @@ static void vmx_inject_nmi(struct kvm_vcpu *vcpu)
static void vmx_update_window_states(struct kvm_vcpu *vcpu)
{
u32 guest_intr = vmcs_read32(GUEST_INTERRUPTIBILITY_INFO);
+ int rmode = vcpu-arch.rmode.active;
vcpu-arch.nmi_window_open =
- !(guest_intr (GUEST_INTR_STATE_STI |
- GUEST_INTR_STATE_MOV_SS |
+ (rmode || !(guest_intr GUEST_INTR_STATE_STI))
+ !(guest_intr (GUEST_INTR_STATE_MOV_SS |
GUEST_INTR_STATE_NMI));
if (!cpu_has_virtual_nmis() to_vmx(vcpu)-soft_vnmi_blocked)
vcpu-arch.nmi_window_open = 0;
vcpu-arch.interrupt_window_open =
((vmcs_readl(GUEST_RFLAGS) X86_EFLAGS_IF)
-!(guest_intr (GUEST_INTR_STATE_STI |
-GUEST_INTR_STATE_MOV_SS)));
+ (rmode || !(guest_intr GUEST_INTR_STATE_STI))
+!(guest_intr GUEST_INTR_STATE_MOV_SS));
}
static int vmx_interrupt_allowed(struct kvm_vcpu *vcpu)
--
1.6.2
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] do not keep interrupt window closed by sti in real mode
Glauber Costa wrote: While in real mode, sti does not block interrupts from the subsequent instruction. This is stated at Intel SDM Volume 2b, page 4-432 I don't see how you're getting that idea from the STI documentation -- and I am quite sure that that is not the case. Quite on the contrary. The only differences between protected mode and real mode has to do with the handling of VIF when CPL=3 (this rather naturally falls out if one considers CPL=0 in real mode). The text is: If protected-mode virtual interrupts are not enabled, STI sets the interrupt flag (IF) in the EFLAGS register. After the IF flag is set, the processor begins responding to external, maskable interrupts after the next instruction is executed. The delayed effect of this instruction is provided to allow interrupts to be enabled just before returning from a procedure (or subroutine). For instance, if an STI instruction is followed by an RET instruction, the RET instruction is allowed to execute before external interrupts are recognized1. If the STI instruction is followed by a CLI instruction (which clears the IF flag), the effect of the STI instruction is negated. Obviously, in real mode, protected-mode virtual interrupts are not enabled, as is also confirmed by Table 4-5. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] do not keep interrupt window closed by sti in real mode
H. Peter Anvin wrote: Glauber Costa wrote: While in real mode, sti does not block interrupts from the subsequent instruction. This is stated at Intel SDM Volume 2b, page 4-432 I don't see how you're getting that idea from the STI documentation -- and I am quite sure that that is not the case. Quite on the contrary. The only differences between protected mode and real mode has to do with the handling of VIF when CPL=3 (this rather naturally falls out if one considers CPL=0 in real mode). I'm guessing the problem is due to the second instruction. We don't clear the 'blocked by interrupt shadow' flag when we emulate, which extends interrupt shadow by one more instruction. If the instruction sequence is 'sti hlt' we end in an inconsistent state. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange guest slowness after some time
Rusty Russell schrieb: On Tuesday 07 April 2009 00:49:17 Tomasz Chmielewski wrote: Tomasz Chmielewski schrieb: As I mentioned, it was using virtio net. Guests running with e1000 (and virtio_blk) don't have this problem. Also, virtio_console seem to be affected by this slowness issue. I'm pretty sure this is different. Older virtio_console code ignored interrupts and polled, and use a heuristic to back off on polling (this was because we used the generic hvc infrastructure which hacked support). By older you mean guest drivers? I have 2.6.27.x on guests and see this issue. If you meant host, I use kvm-84. You'll find a delay on the first keystroke after idle, but none on the second. I'm not sure. Press a seven times fast, and 7 characters will be printed a second later. But: wait one second more, it will be unresponsive again. You won't see the characters as you type. Also these symptoms are very similar to virtio_net issue: - it happens only on some guest (even if they have the same kernel and userspace) after a random period of time - it used to happen for me _always_ when network got slow with virtio_net driver - it doesn't go away with guest restart initiated from guest's system - it goes away with kvm process stop/start (i.e. new kvm process), but can appear later with no apparent cause -- Tomasz Chmielewski http://wpkg.org -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Upstream QEMU vs kvm modified for ARM implementation
Hi Hollis. Thanks a lot for getting back to us. The PPC code is indeed very intelligible... We took the approach, which you recommended earlier regarding test code, and are writing kind of a test harness in the same spirit, which we will eventually throw into the QEMU source. Previously we were informed on the KVM #irc channel that the QEMU upstream version of KVM was not functional, but I guess it was s mild overstatement then. A few questions regarding the upstream version: - Apart from issues like SMP, are you aware of any specific problems with the upstream version that we should be aware of? - Does the upstream QEMU code use the libkvm code as well or is all the logic placed in kvm-all.c and in the target specific kvm.c files? - Is compiling against a patched kernel (as opposed to using a module) and doing sync-headers from custom source supported in the upstream version? Any specific tag of the QEMU git repository you recommend working from, or would the latest commit usually be trustworthy? :) Regarding the design of things, why was it necessary to hijack all interrupt vectors in the kernel. We are wondering if it wouldn't be sufficient to hijack synchronous interrupts and let QEMU take care of all I/O, timer interrupts etc. Are we missing something here? Regards, Christoffer Dall Andreas Nilsson Columbia University On Tue, Apr 7, 2009 at 2:11 PM, Hollis Blanchard holl...@us.ibm.com wrote: On Tue, 2009-04-07 at 12:41 -0400, Christoffer Dall wrote: Hi. As we indicated earlier, we are working on an ARM version of KVM and taking some inspiration from the PPC version. I hope the PPC code is intelligible to you... feel free to ask if you have design questions we can help clarify. We have done some amount of kernel side development and are now looking more into adapting QEMU. By the way, you can start with kvm-userspace/test/ code to begin exercising your kernel interface before qemu is ready. First, is it correct that the PPC port of KVM uses the kvm-all.c files and thus the upstream QEMU support for KVM? Correct. Second, for an ARM version, which takes the same approach with replacing interrupt vectors in the kernel as PPC, would the best approach be to continue with the upstream QEMU version or try to use the structure used in the by qumranet modified qemu version for x86_64? There isn't an architectural split like that (PowerPC - upstream, x86 - Qumranet). Previously, all KVM support (including PowerPC) was in the Qumranet fork, but now upstream has support for PowerPC and x86. There are still features that need to be migrated upstream though (e.g. guest SMP). You should base your work on upstream qemu. If you base it on the Qumranet fork, nobody will migrate your code upstream for you, and long term that fork is expected to disappear (when upstream becomes feature-complete). Also, the interrupt vectors thing really doesn't matter... the kernel provides an interface, and how exactly that's implemented doesn't matter to qemu. Last, we are using the kvm-84 release of userspace kvm and QEMU - would this also be what you would recommend working with? Use qemu.git (http://git.kernel.org/?p=virt/qemu/qemu.git;a=summary). -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Upstream QEMU vs kvm modified for ARM implementation
On Tue, 2009-04-07 at 14:30 -0400, Christoffer Dall wrote: A few questions regarding the upstream version: - Apart from issues like SMP, are you aware of any specific problems with the upstream version that we should be aware of? I don't know the full status off the top of my head (you might ask on qemu-devel), but many of them don't matter on non-x86 platforms. For example, I think qemu still doesn't support x86's in-kernel APIC emulation... but that's irrelevant for us. - Does the upstream QEMU code use the libkvm code as well or is all the logic placed in kvm-all.c and in the target specific kvm.c files? The latter. libkvm has a questionable future. - Is compiling against a patched kernel (as opposed to using a module) and doing sync-headers from custom source supported in the upstream version? I have only used a real kernel build. I've had nothing but trouble with the kvm-userspace/kernel directory. Also, for technical reasons, the 440/e500 KVM build doesn't work as a module (we assume we will not take a TLB miss when handling guest exits). Any specific tag of the QEMU git repository you recommend working from, or would the latest commit usually be trustworthy? :) The latest is fairly trustworthy. There is a relatively high patch rate, but most of it is in areas that don't affect us. Regarding the design of things, why was it necessary to hijack all interrupt vectors in the kernel. We are wondering if it wouldn't be sufficient to hijack synchronous interrupts and let QEMU take care of all I/O, timer interrupts etc. Are we missing something here? We would love to do that, but the biggest problem is that the host interrupt handlers don't know about guest state. PowerPC hardware does not switch the stack pointer for you; it's a software decision. When the host kernel sees the interrupt occurred in user mode, it switches the stack pointer to the top of the kernel stack. (If the interrupt occurred in kernel mode, the stack pointer is just decremented, preserving the kernel call stack.) When we run the guest, we run it in user mode. Since that's done via ioctl, there are frames from the ioctl path on the kernel stack. So if a host handler sees came from user mode and resets the kernel stack, we will clobber the ioctl stack frames. Anyways, the really high-level overview of our async handler path is that we restore host kernel register state then re-invoke the interrupt, so the host handlers will deal with it anyways. Note that (in general) with KVM, Qemu only handles IO. KVM handles all core emulation, including instructions, the MMU, and the decrementer (PowerPC's in-core timer interrupt source). -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
