[kvm-devel] Windows guest reboot failure
Hi folks, I found that Windows guests often fail reboots in current kvm.git. Either the guest hangs, or it reports double fault exception which causes qemu aborts. This is not shown with -no-kvm-irqchip option. After some investigation, it seems that this is caused by lack of in-kernel components reset. Several windows guests will write RESET command to 8042, the keyboard controller. On receiving the command, qemu device model will call qemu_system_reset() to reset everything to the initial state. However, this mechanism is broken when in-kernel components is introduced: qemu doesn't communicate the reset request to kvm, so kvm uses stale device state on the next booting, which fails reboot. To resolve this, there are at least two options: 1. modify qemu_system_reset(), so that qemu destroys kvm context and re-creates. 2. introduce a new ioctl, say KVM_RESET, to kvm. On receiving this ioctl, the kernel calls reset handlers registered by other components (vcpu, lapic, pic, ioapic, pit, etc.), either against vm or against each vcpu. IMO, the first one is easier in modification and maintaining, but the second one is closer to qemu logics. Which do you think is more appropriate? Any comment? Thanks, Qing - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
Hi, is this the same layout introduced for the powerpc port ? Perhaps you should work together ? Laurent Zhang, Xiantao wrote: Hi Folks, We are working on enabling KVM support on IA64 platform, and now Linux, Windows guests get stable run and achieve reasonable performance on KVM with Open GFW. But you know, the current KVM only considers x86 platform, and is short of cross-architecture framework. Currently, we have a proposal for KVM source layout to accommodate new CPU architectures. Attached foil describes the detail. With our proposal, we can boot x86 guests based on commit 2e278972a11eb14f031dea242a9ed118adfa0932, also didn't see regressions. For IA64 side, we are rebasing our code to this framework. Main changes to current source: 1. Add subdirectories, such as x86 and ia64 to hold arch-specific code. 2. Split kvm_main.c to two parts. One is still called kvm_main.c, just contains KVM common interfaces with user space, and basic KVM infrastructure. The other one is named as kvm_arch.c under sub-directory (eg. X86, ia64 etc), which includes arch-specific code to supplement the functionality of kvm_main.c 3. Add an include directory in drivers/kvm. Due to possibly complex code logic in KVM source, maybe many header files need to maintain for some architectures. If we put them under top-level include/asm-arch directory, it may introduce much more maintain effort. So, we put it under drivers/kvm, and let it be effective when kernel configuration time. BTW, Userspace code changes are not involved in this thread. Considering the readability, we didn't attach the diff file in the mail, due to big changes to kvm source structure, and only post the tarball including whole directory drivers/kvm instead. For comparison, I attached kvm_main.diff as well. Any comments are appreciated from you! Hope to see IA64 support on KVM earlier! Thanks Best Wishes Xiantao Intel Opensource Technology Center. * BLOCKED FILE ALERT!* The attachment '.kvm-intel.ko.cmd' has been blocked because it is a disallowed file type. The attachment has been replaced by this message. If you feel you have received this message in error and are an Intel employee, then please contact the Global Service Desk http://servicedesk.intel.com. More Information: If you are an Intel employee and internal to the Intel network, visit Secure Intel http://secure.intel.com/infosec/response_services/pc+and+network+protection/email+security/email+security.htm to learn more about E-mail attachment options. If you are not an Intel employee, please contact your Intel sponsor for additional information. http://it.intel.com Copyright © Intel Corporation, 2002-2006. All rights reserved. *Other names and brands may be claimed as the property of others. **Intel is not responsible for content of sites outside our intranet. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Windows guest reboot failure
He, Qing wrote: Hi folks, I found that Windows guests often fail reboots in current kvm.git. Either the guest hangs, or it reports double fault exception which causes qemu aborts. This is not shown with -no-kvm-irqchip option. After some investigation, it seems that this is caused by lack of in-kernel components reset. Several windows guests will write RESET command to 8042, the keyboard controller. On receiving the command, qemu device model will call qemu_system_reset() to reset everything to the initial state. However, this mechanism is broken when in-kernel components is introduced: qemu doesn't communicate the reset request to kvm, so kvm uses stale device state on the next booting, which fails reboot. To resolve this, there are at least two options: 1. modify qemu_system_reset(), so that qemu destroys kvm context and re-creates. That's too destructive, there's lots of state to recreate, things like dirty page logging need to be reinitialized. 2. introduce a new ioctl, say KVM_RESET, to kvm. On receiving this ioctl, the kernel calls reset handlers registered by other components (vcpu, lapic, pic, ioapic, pit, etc.), either against vm or against each vcpu. There's a third option: let the regular qemu logic work, and after that copy the state to kvm (just like after vm restore). I tried that but there were problems so I dropped it. But the approach should work. IMO, the first one is easier in modification and maintaining, but the second one is closer to qemu logics. Which do you think is more appropriate? I think #2. Synchronization will be difficult; we'll need to send signals to all other vcpus so that they drop the vcpu mutex. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23-rc8-mm1: drivers/kvm/ioapic.o build failure
Mariusz Kozlowski wrote: Hello, Similar (the same?) as in 2.6.23-rc6-mm1? http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg208812.html CC [M] drivers/kvm/ioapic.o drivers/kvm/ioapic.c: In function 'ioapic_deliver': drivers/kvm/ioapic.c:208: error: 'dest_LowestPrio' undeclared (first use in this function) drivers/kvm/ioapic.c:208: error: (Each undeclared identifier is reported only once drivers/kvm/ioapic.c:208: error: for each function it appears in.) drivers/kvm/ioapic.c:219: error: 'dest_Fixed' undeclared (first use in this function) make[2]: *** [drivers/kvm/ioapic.o] Error 1 make[1]: *** [drivers/kvm] Error 2 make: *** [drivers] Error 2 We now include asm/io_apic.h like we should. Has that file changed in -mm? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-40 and above: Win XP SP2 install crashes on AMD64 2.6.22.5-49
Klaus Kudielka wrote: Hello, Starting with kvm-40, I am not able to install a Win XP SP2 guest any more. I consistently get a BSOD somewhere in the 2nd stage install. Sometimes it is IRQL_NOT_LESS_OR_EQUAL, otherwise STOP: 0x008E or STOP: 0x000A In most failure cases I also get a kernel message: emulation failed (mmio) rip 426 c4 c4 00 00 The hardware is an AMD Athlon(tm) 64 Processor 3500+ with 3G of RAM. The host is a FC6 installation with a pretty recent kernel (2.6.22.5-49) I configured kvm only with --prefix=/opt/kvm The command to run the installation was /opt/kvm/bin/qemu-system-x86_64 -no-acpi -hda /dev/Guests/xp_kvm -m 1024 -net nic,mac=00:16:3e:11:80:49,model=rtl8139 -cdrom /d/3/oe1kib/img/windows_xp_sp2_en.iso -boot d I always select the Standard PC HAL during install. On kvm-39 36, the install completes fine. On kvm-40,41,43,44 it fails with the symptoms described above. I have not tested others, but the tendency seems clear. [With -no-kvm, qemu-system-x86_64 does not crash the guest, but Win XP seems to be Installing Devices for the rest of its life. The session is alive, but no progress anymore. Likely a different problem] Any idea? Or even a fix? Can you do a bisect to find which commit caused the breakage? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] virtio ring implementation
Rusty Russell wrote: On Tue, 2007-09-25 at 19:15 +0200, Dor Laor wrote: At the moment it's not good enough, there is a potential race were the guest optimistically turn off the VRING_AVAIL_F_NO_INTERRUPT in the vring_restart and afterwards finds there are more_used so it consume them in the poll function. If in the middle, packets arrive the host will see the flag is off and send irq. In that case the above irq handler will report IRQ_NONE. Good point. On the one hand, reporting IRQ_NONE occasionally is not fatal. On the other, it'd be nice to get this right. It's also not trivial to cancel the optimistic approach in the restart function since then there might be another race that will result in missing irq reaching the guest. I did it optimistically because otherwise we need two barriers (and still have a window). I'll try to think of something better than a hypercall for switching irq on/off. Erk. That would be v. bad... Actually double barrier will satisfy non-shared irq lines and will report irq handling right. The more complex scenario is shared irqs (pci...), since several devices are raising the irq line (level triggered) in the same time, while the tap add receive packets it always leaves a potential race for irq handled return value. So seems like we better not have shared irq and if only if shared irq is a must we should do the naughty naughty things. If returning IRQ_NONE once in a while is not too bad (including the matching windows implementation) then there is no issue. Dor. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23-rc8-mm1: drivers/kvm/ioapic.o build failure
On Wed, 26 Sep 2007 11:00:09 +0200 Avi Kivity [EMAIL PROTECTED] wrote: Mariusz Kozlowski wrote: Hello, Similar (the same?) as in 2.6.23-rc6-mm1? http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg208812.html CC [M] drivers/kvm/ioapic.o drivers/kvm/ioapic.c: In function 'ioapic_deliver': drivers/kvm/ioapic.c:208: error: 'dest_LowestPrio' undeclared (first use in this function) drivers/kvm/ioapic.c:208: error: (Each undeclared identifier is reported only once drivers/kvm/ioapic.c:208: error: for each function it appears in.) drivers/kvm/ioapic.c:219: error: 'dest_Fixed' undeclared (first use in this function) make[2]: *** [drivers/kvm/ioapic.o] Error 1 make[1]: *** [drivers/kvm] Error 2 make: *** [drivers] Error 2 We now include asm/io_apic.h like we should. Has that file changed in -mm? CONFIG_X86_IO_APIC isn't set. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23-rc8-mm1: drivers/kvm/ioapic.o build failure
Andrew Morton wrote: On Wed, 26 Sep 2007 11:00:09 +0200 Avi Kivity [EMAIL PROTECTED] wrote: Mariusz Kozlowski wrote: Hello, Similar (the same?) as in 2.6.23-rc6-mm1? http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg208812.html CC [M] drivers/kvm/ioapic.o drivers/kvm/ioapic.c: In function 'ioapic_deliver': drivers/kvm/ioapic.c:208: error: 'dest_LowestPrio' undeclared (first use in this function) drivers/kvm/ioapic.c:208: error: (Each undeclared identifier is reported only once drivers/kvm/ioapic.c:208: error: for each function it appears in.) drivers/kvm/ioapic.c:219: error: 'dest_Fixed' undeclared (first use in this function) make[2]: *** [drivers/kvm/ioapic.o] Error 1 make[1]: *** [drivers/kvm] Error 2 make: *** [drivers] Error 2 We now include asm/io_apic.h like we should. Has that file changed in -mm? CONFIG_X86_IO_APIC isn't set. Why should that matter? we're just pulling that file for the definitions. I'll try to compile without it here and see how it breaks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1802580 ] 64bit linux cannot get ip
Bugs item #1802580, was opened at 2007-09-26 17:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1802580group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: 64bit linux cannot get ip Initial Comment: In the testing for kvm.git 5ed6627ee96f0a6802d99e71879d98610ba17e01 and kvm-userspace.git 1de8b6722138b89ec471ceb5c8c8def17d963d1d, all 64bit linux guests cannot get ip from dhcp. and 32bit linux guests hasn't this issue. If reinstalled the binary rpm of kvm.git 2cd2d1d11d1f67c4d660c0cf6758dd6e588c4dd6, the issue will be dispeared. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1802580group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Windows guest reboot failure
I think #2. Synchronization will be difficult; we'll need to send signals to all other vcpus so that they drop the vcpu mutex. How about add a new ABI KVM_RESET_KERNDEVS ? We don't want to implement RESET ABIs for each kernel devices especially when we move PIT down and then RTC, pmtimer etc. Eddie - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] system time
hi, there is a strange thing which is just noticed. on our kvm host there is a ntpd running and synchronize to some time server and it's time is valid. so i decided that i won't run ntpd on the guest vms since if the host has the right time probably the guest see the same time. but that's not the case! there is almost a minute difference between the host and the guests (all guest has different time). shouldn't the guest see the host as it's base/bios time? or how it's working? it'd be better to run ntpd on all guest? why? -- Levente Si vis pacem para bellum! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] system time
Frakas, I just noticed the same thing. This never used to be the case though as usually they would be exactly the same time. On 9/26/07, Farkas Levente [EMAIL PROTECTED] wrote: hi, there is a strange thing which is just noticed. on our kvm host there is a ntpd running and synchronize to some time server and it's time is valid. so i decided that i won't run ntpd on the guest vms since if the host has the right time probably the guest see the same time. but that's not the case! there is almost a minute difference between the host and the guests (all guest has different time). shouldn't the guest see the host as it's base/bios time? or how it's working? it'd be better to run ntpd on all guest? why? -- Levente Si vis pacem para bellum! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] 蠕动泵、恒流泵、耐有机溶剂泵头
Title: 保定普赛思恒流泵有限公司 易装型泵头： YZ1515x，YZ2515x型泵头采用PPS―聚苯硫醚材料，其刚性及结性能更加出众，具备超强的耐高温性、抗腐蚀性，尤其在抗有机溶剂等强化学腐蚀方面表现优异，有效减少了泵头损坏率，使客户的维修、维护成本大大降低。 在蠕动泵正常工作的情况下，液体只接触软管，这是蠕动泵的主要特点之一。但是，软管是有使用寿命的，由于长期摩擦，或者输送腐蚀性液体，软管会逐渐老化，甚至破裂，一旦腐蚀性液体渗漏，首先会接触泵头，我们在使用中常常遇到泵头酥裂的问题，就是因为泵头的材料不耐腐蚀，这会中断我们的生产、试验或教学，带来不必要的损失，而PPS-聚苯硫醚材料的泵头使我们不再为此而担忧！聚苯硫醚泵头精度高，耐高温，抗腐蚀，尤其在抗有机溶剂等强化学腐蚀方面表现优异，它拓宽了蠕动泵的使用范围。 产品介绍： 可装YZ1515x,YZ2515x,DG-1,DG-2等多种泵头,能提供0.05-380ml/min的流量范围；采用大屏幕液晶显示运行界面,直接显示流量,简洁直观,人机界面友好；具有流量校正功能,无需手动调节,高精度传输液体的同时,有效提高工作效率；具有多种外控方式,可以通过0－5V,0-10V,4-20mA三种外控接口控制,也可以通过RS485通讯接口实现外部控制。 主要功能和特点 ・可在流量显示与转速显示两种方式之间切换 ・具有流量校准功能，使得流量控制更精确，适合定量传输液体 ・大屏图形点阵液晶与脉冲编码开关配合使用，人机界面更加友好，用户使用更加便捷 ・具备通迅接口，可为用户提供通迅协议，也可按用户要求订制上位机软件 ・高性价比。 型号：BT100-1L 类别：蠕动泵 流量型 参考流量：0.07-380mL/min 产品介绍： 可装YZ1515x,YZ2515x,DG-1,DG-2等多种泵头,能提供0.07-1140ml/min的流量范围； 可显示液量分配功能，直接显示分 配液量，分配次数，时间间隔，回吸角度，无需使用分配 控制器，简便直观，在应用中即降低对操作人员的技术要求，又 降低误操作率，为客户减少损失，显著提高工作效率；采用大屏 幕液晶显示运行界面,直人机界面友好；具有多种外控方式,可以 通过0－5V,0-10V,4-20mA三种外控接口控制,也可以通过RS485通 讯接口实现外部控制。主要功能和特点 ・可安装两种种泵头:YZ1515x、YZ2515x ・可设置分配液量，实现自动分配灌装 ・显示流量或转速，以及分配液量值 ・对设定的流量进行校正，从而获得最精确的流量值，适合定时 定量传输液体 ・具备通迅接口，可为用户提供通迅协议，也可按用户要求订制 上位机软件 型号：BT300-1F 类别：蠕动泵 分配型 参考流量：0.07-1140mL/min 产品介绍： 可装YZ1515x,YZ2515x,DG-1,DG-2,DG-4,DG-6等多种泵头,可带双泵头工作,能提供0.07-2280ml/min的流量范围； 转速可以手动调节,也可以外控方式实现自动控制,三种外接方式 可供选择:0－5V,0-10V,4-20mA;与FK-1c分装控制器配合使用,可 以实现灌装功能,具有掉电记忆功能,操作简单直观。 主要功能和特点 ・可安装多种泵头：YZ1515x、YZ2515x、DG系列泵头 ・转速高，流量大，功耗低 ・设有全速按钮：具有填充、排空功能 ・转速可手动调节，也可通过外控接口进行自动控制 ・可与分装控制器配合，实现灌装功能 ・大转矩，低功耗，适应性强 ・驱动电路性能优良，散热条件好，工作噪音小，运行平稳，具有掉电记忆功能。 ・不适于户外使用 型号：BT00-600M 类别：蠕动泵 基本型 参考流量：0.07-2280mL/min 白金硫化的卫生级硅胶管；疏水性内表面，提高流动性；内壁极其光滑、吸附性低，析出物极低，生物相容性可达ISO10993标准，符合美国USP Class VI，FDA及NSF相关标准。 可在蠕动泵上长时间使用，寿命比硅胶管长数倍。可重复高温高压灭菌消毒；符合美国USP Class VI、FDA及NSF相关标准；其生物相容性可达ISO10993标准；气密性比硅胶管强60倍。 可耐绝大部分强酸、强碱、燃油，有机溶剂等；可在最高204℃环境下长期使用；具有很强的耐臭氧及耐候性；弹性、柔韧性出色，是输送强腐蚀介质用理想的蠕动泵管。 ―― 【注意】上面的邮件内容与以下文字无关。本软件仅限于合法用途! 该邮件由《Volleymail邮件群发专家》软件发送；被网友评为最厉害 的邮件群发软件而多次要求破解！现免费下载，无限时间使用。 详情请访问我们的主页：『艺泰』软件工作室- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
Re: [kvm-devel] [ kvm-Bugs-1802223 ] nics have same hw address (rtl8139)
Hi, I think there is a bug in qemu RTL8139. RTL8139 uses: cpu_register_physical_memory(addr + 0, 0x100, s-rtl8139_mmio_io_addr); But in the comment of cpu_register_physical_memory() we have: 'size' must be a multiple of the target page size. And I think 0x100 is not a multiple of target page size :-P The attached patch corrects the problem. Laurent SourceForge.net wrote: Bugs item #1802223, was opened at 2007-09-25 22:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1802223group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: xeb (xebd) Assigned to: Nobody/Anonymous (nobody) Summary: nics have same hw address (rtl8139) Initial Comment: Hello! Host:Linux 2.6.22-gentoo-r2 #2 SMP Fri Aug 3 07:01:46 MSD 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ AuthenticAMD GNU/Linux,Gentoo, kvm-44 Guest:Linux 2.6.22-hardened-r4 command line: qemu-system-x86_64 -hda server_base_x86.img -hdc server_swap.img -localtime -m 128 \ -net nic,vlan=0,macaddr=52:54:00:12:34:56,model=rtl8139 -net tap,vlan=0,ifname=tap3,script=no \ -net nic,vlan=1,macaddr=52:54:00:12:34:57,model=rtl8139 -net tap,vlan=1,ifname=tap4,script=no \ -net nic,vlan=2,macaddr=52:54:00:12:34:58,model=rtl8139 -net tap,vlan=2,ifname=tap5,script=no \ -nographic ifconfig on guest: eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:58 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:11 Base address:0x4000 eth1 Link encap:Ethernet HWaddr 52:54:00:12:34:58 inet addr:192.168.11.1 Bcast:192.168.11.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:9 Base address:0x6100 eth2 Link encap:Ethernet HWaddr 52:54:00:12:34:58 inet addr:192.168.13.1 Bcast:192.168.13.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:11 Base address:0x8200 As can you see they have same hwaddr. With model=ne2k_pci nics have correct hw addresses Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth rtl8139.patch Description: application/mbox signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ kvm-Bugs-1802223 ] nics have same hw address (rtl8139)
On Wed, Sep 26, 2007 at 05:47:20PM +0200, Laurent Vivier wrote: Hi, I think there is a bug in qemu RTL8139. RTL8139 uses: cpu_register_physical_memory(addr + 0, 0x100, s-rtl8139_mmio_io_addr); But in the comment of cpu_register_physical_memory() we have: 'size' must be a multiple of the target page size. And I think 0x100 is not a multiple of target page size :-P Latest upstream QEMU has fixed its memory handling so that MMIO regions do not need to be a multiple of page size. Changing RTL8139 to use a block of size 0x1000 is a reasonable short term hack around the problem, but syncing with latest QEMU is the real solution, since there are other places in the code which will have similar issues. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ kvm-Bugs-1802223 ] nics have same hw address (rtl8139)
Daniel P. Berrange wrote: On Wed, Sep 26, 2007 at 05:47:20PM +0200, Laurent Vivier wrote: Hi, I think there is a bug in qemu RTL8139. RTL8139 uses: cpu_register_physical_memory(addr + 0, 0x100, s-rtl8139_mmio_io_addr); But in the comment of cpu_register_physical_memory() we have: 'size' must be a multiple of the target page size. And I think 0x100 is not a multiple of target page size :-P Latest upstream QEMU has fixed its memory handling so that MMIO regions do not need to be a multiple of page size. Changing RTL8139 to use a block of size 0x1000 is a reasonable short term hack around the problem, but syncing with latest QEMU is the real solution, since there are other places in the code which will have similar issues. So this explains why rtl8139.c from QEMU CVS always uses 0x100. Thank you for the comment. Avi, you know what you have to do ;-) Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm, ubuntu 7.10 vmware
Jared Greenwald wrote: I'm trying to get a pre-built vmware image of Windows running on ubuntu 7.10. I tried running qemu directly on the vmdk file, but that is extremely slow. For example, it takes about a minute to get the context menu to come up when you right-click on the desktop. I tried converting the vmdk to qcow, qcow2 and raw formats, but I get an error saying that the drive is not bootable. I looked through the help pages and there is information about loading the kvm-intel module, but I'm getting the not supported error message. I looked into updating the bios as this is usually pointed to as the cause and it appears I'm at the most recent version. So, the question is, am I missing something or am I doing something wrong? To be clear, are you running modprobe kvm_intel and it's returning not supported? Did you install kvm with apt-get? When you run cat /proc/cpuinfo | grep flags, do you see vmx in the list of flags? Cam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] use of saved_eip
Hi Vivier, Avi, In order to debug faulures in my tree, I was looking at the saved_eip changes coming from your commit. I did not understand the use of saved_eip properly. like why is it used in the emulation of the pop instruction. Can you please help me understand it's usage? commit 5d9b36eec8ca6abe03da91efdfc7b5861525bd43 Author: Laurent Vivier [EMAIL PROTECTED] Date: Tue Sep 18 11:27:37 2007 +0200 KVM: Call x86_decode_insn() only when needed Move emulate_ctxt to kvm_vcpu to keep emulate context when we exit from kvm module. Call x86_decode_insn() only when needed. Modify x86_emulate_insn() to not modify the context if it must be re-entered. Signed-off-by: Laurent Vivier [EMAIL PROTECTED] Signed-off-by: Avi Kivity [EMAIL PROTECTED] Thanks Regards, Nitin Linux Open Source Technology Center, Intel Corporation The Mind is like a parachute; it works much better when it's open. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-40 and above: Win XP SP2 install crashes on AMD64 2.6.22.5-49
On Wed, Sep 26, 2007 at 01:51:26PM +0200, Izik Eidus wrote: can you try runing it with -no-kvm-irqchip, and report the results? pretty much the same. I tried -40 and -44 and they both fail with the same symptom described previously. Regards, Klaus - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] use of saved_eip
Kamble, Nitin A wrote:
Hi Vivier, Avi,
Hi Nitin,
(BTW, my first name is Laurent)
In order to debug faulures in my tree, I was looking at the saved_eip
changes coming from your commit. I did not understand the use of
saved_eip properly. like why is it used in the emulation of the pop
instruction. Can you please help me understand it's usage?
in emulate_instruction(), we decode instructions and copy vcpu registers
to ctxt (in x86_decode_insn()), then we really emulate the instruction
(in x86_emulate_insn()).
In x86_emulate_insn(), if we have a REP prefix, we decrement ECX and set
EIP to next instruction, then we try to emulate the instruction.
If the emulation fails (because this is a MMIO for instance) we have to
restore the initial values of ECX and EIP because we will re-enter in
x86_emulate_insn() once the IO has been managed by Qemu and thus ECX is
decremented again and EIP set to next instruction again.
And you are right: _we_don't_have_to_do_that_for_the_pop_instruction_,
it's a mistake because the REP prefix hasn't been processed at this
level, it is managed (ECX and EIP are modified) later.
So, you can remove from pop_instruction:
1383 if (c-rep_prefix) {
1384 c-regs[VCPU_REGS_RCX] = saved_rcx;
1385 c-eip = saved_eip;
1386 }
Sorry for the inconvenience,
Laurent
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm, ubuntu 7.10 vmware
Jared Greenwald wrote: On 9/26/07, Cam Macdonell [EMAIL PROTECTED] wrote: Jared Greenwald wrote: I'm trying to get a pre-built vmware image of Windows running on ubuntu 7.10. I tried running qemu directly on the vmdk file, but that is extremely slow. For example, it takes about a minute to get the context menu to come up when you right-click on the desktop. I tried converting the vmdk to qcow, qcow2 and raw formats, but I get an error saying that the drive is not bootable. I looked through the help pages and there is information about loading the kvm-intel module, but I'm getting the not supported error message. I looked into updating the bios as this is usually pointed to as the cause and it appears I'm at the most recent version. To be clear, are you running modprobe kvm_intel and it's returning not supported? Did you install kvm with apt-get? yes, I used this page https://help.ubuntu.com/community/KVM which says to: apt-get install kvm qemu When do you get the not supported error? Have you ever had KVM running with VMs other than this Windows one? On another note, if you just want to run a VMware image, have you thought of trying VMware Player? Cam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] use of saved_eip
Hi Laurent,
Sorry for calling by alst name. You 1st last both names are totally
new to me. Are these french names?
I understand your explanation. I was worried about code getting
misplaced due to automatic merges.
--
Thanks Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; it works much better when it's open
On Wed, 2007-09-26 at 14:51 -0700, Laurent Vivier wrote:
Kamble, Nitin A wrote:
Hi Vivier, Avi,
Hi Nitin,
(BTW, my first name is Laurent)
In order to debug faulures in my tree, I was looking at the
saved_eip
changes coming from your commit. I did not understand the use of
saved_eip properly. like why is it used in the emulation of the pop
instruction. Can you please help me understand it's usage?
in emulate_instruction(), we decode instructions and copy vcpu
registers
to ctxt (in x86_decode_insn()), then we really emulate the instruction
(in x86_emulate_insn()).
In x86_emulate_insn(), if we have a REP prefix, we decrement ECX and
set
EIP to next instruction, then we try to emulate the instruction.
If the emulation fails (because this is a MMIO for instance) we have
to
restore the initial values of ECX and EIP because we will re-enter in
x86_emulate_insn() once the IO has been managed by Qemu and thus ECX
is
decremented again and EIP set to next instruction again.
And you are right: _we_don't_have_to_do_that_for_the_pop_instruction_,
it's a mistake because the REP prefix hasn't been processed at this
level, it is managed (ECX and EIP are modified) later.
So, you can remove from pop_instruction:
1383 if (c-rep_prefix) {
1384 c-regs[VCPU_REGS_RCX] =
saved_rcx;
1385 c-eip = saved_eip;
1386 }
Sorry for the inconvenience,
Laurent
signature.asc
Description: This is a digitally signed message part
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
