[ kvm-Bugs-2924683 ] Stable USB Windows XP BSOD with Epson V700 scanner
Bugs item #2924683, was opened at 2010-01-01 23:53 Message generated for change (Tracker Item Submitted) made by akunitskiy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2924683&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: marten (akunitskiy) Assigned to: Nobody/Anonymous (nobody) Summary: Stable USB Windows XP BSOD with Epson V700 scanner Initial Comment: kvm causes stable BSOD in Windowsx XP / XP 64 with Epson V700 USB scanner. How I can help to fix this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2924683&group_id=180599 -- 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: Testing nested virtualization
On Friday, 01 January 2010 17:20:00 -0300, Daniel Bareiro wrote: > In this guest I'm using Linux 2.6.32, with userspace kvm-85 of > backports. For the VM booted within of 'test', I am using a qcow2 > file. But when connecting via VNC, the boot process is hung in "Press > for F12 boot menu". Sometimes it gets to pass this instance and I see > the Debian install menu, but while I cross the options, it is hung. Also I was trying to use qemu-kvm-0.12.1.1 with to Linux 2.6.32 in guest within 'test'. And here it happens something similar. Sometimes I get to select the option of the menu of the installer, but after boot, the installation is hung again. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature
Testing nested virtualization
Hi, all! I'm testing nested virtualization with Linux 2.6.32.2 and qemu-kvm-0.12.1.1 in the host. I was looking for if in the KVM official site there is something documented, but I didn't find information so any reference will be welcome. What I got to do until the moment is to load the module in host of the following way: # modprobe kvm_amd nested=1 Then, to boot guest with the parameter -enable-nesting: # /usr/local/qemu-kvm/bin/qemu-system-x86_64 -hda /dev/vm/test-disk -m \ 1024 -boot c -net nic,vlan=0,macaddr=00:16:3e:00:00:34 -net tap \ -daemonize -vnc :3 -k es -localtime -serial \ telnet:localhost:5000,server,nowait -monitor \ telnet:localhost:5001,server,nowait -enable-nesting In this guest I'm using Linux 2.6.32, with userspace kvm-85 of backports. For the VM booted within of 'test', I am using a qcow2 file. But when connecting via VNC, the boot process is hung in "Press for F12 boot menu". Sometimes it gets to pass this instance and I see the Debian install menu, but while I cross the options, it is hung. With these options I boot the guest within test: # kvm -hda disk01.img -m 512 -boot d -cdrom debian-500-amd64-netinst.iso \ -net nic,vlan=0,macaddr=00:16:3e:00:00:33 -net tap -daemonize -vnc :2 \ -k es -localtime Which can be the problem? Thanks in advance for your replies. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature
[SeaBIOS] [PATCH] Make MTRR region 0xc0000-0x100000 be cached.
The current MTRR code in SeaBIOS uses uncached ram for
0xc-0x10. This seems overly pessimistic as "write protect"
should be sufficient. (Note, a WP mtrr does not prevent writes - it
is a caching strategy for memory that can be read-only.)
I'm not sure how much KVM really uses the MTRRs, but if it does honor
them this should make bootup a bit faster as it will allow caching of
the SeaBIOS code.
This change also clears all the variable mtrrs, and makes sure all the
mtrrs are set before they are enabled.
-Kevin
diff --git a/src/mtrr.c b/src/mtrr.c
index 7d1df09..ed239c8 100644
--- a/src/mtrr.c
+++ b/src/mtrr.c
@@ -44,42 +44,42 @@ void mtrr_setup(void)
dprintf(3, "init mtrr\n");
-int i, vcnt, fix, wc;
-u32 mtrr_cap;
-union {
-u8 valb[8];
-u64 val;
-} u;
-
-mtrr_cap = rdmsr(MSR_MTRRcap);
-vcnt = mtrr_cap & 0xff;
-fix = mtrr_cap & 0x100;
-wc = mtrr_cap & 0x400;
+u32 mtrr_cap = rdmsr(MSR_MTRRcap);
+int vcnt = mtrr_cap & 0xff;
+int fix = mtrr_cap & 0x100;
if (!vcnt || !fix)
return;
-// Fixed MTRRs
+// Disable MTRRs
+wrmsr_smp(MSR_MTRRdefType, 0);
+
+// Set fixed MTRRs
+union u64b {
+u8 valb[8];
+u64 val;
+} u;
u.val = 0;
-for (i = 0; i < 8; ++i)
+int i;
+for (i = 0; i < 8; i++)
if (RamSize >= 65536 * (i + 1))
u.valb[i] = MTRR_MEMTYPE_WB;
wrmsr_smp(MSR_MTRRfix64K_0, u.val);
u.val = 0;
-for (i = 0; i < 8; ++i)
-if (RamSize >= 65536 * 8 + 16384 * (i + 1))
+for (i = 0; i < 8; i++)
+if (RamSize >= 0x8 + 16384 * (i + 1))
u.valb[i] = MTRR_MEMTYPE_WB;
wrmsr_smp(MSR_MTRRfix16K_8, u.val);
-wrmsr_smp(MSR_MTRRfix16K_A, 0);
-wrmsr_smp(MSR_MTRRfix4K_C, 0);
-wrmsr_smp(MSR_MTRRfix4K_C8000, 0);
-wrmsr_smp(MSR_MTRRfix4K_D, 0);
-wrmsr_smp(MSR_MTRRfix4K_D8000, 0);
-wrmsr_smp(MSR_MTRRfix4K_E, 0);
-wrmsr_smp(MSR_MTRRfix4K_E8000, 0);
-wrmsr_smp(MSR_MTRRfix4K_F, 0);
-wrmsr_smp(MSR_MTRRfix4K_F8000, 0);
+wrmsr_smp(MSR_MTRRfix16K_A, 0); // 0xA-0xC is uncached
+int j;
+for (j = 0; j < 8; j++) {
+u.val = 0;
+for (i = 0; i < 8; i++)
+if (RamSize >= 0xC + j * 0x8000 + 4096 * (i + 1))
+u.valb[i] = MTRR_MEMTYPE_WP;
+wrmsr_smp(MSR_MTRRfix4K_C + j, u.val);
+}
-// Variable MTRRs
+// Set variable MTRRs
int phys_bits = 36;
cpuid(0x8000u, &eax, &ebx, &ecx, &edx);
if (eax >= 0x8008) {
@@ -88,6 +88,10 @@ void mtrr_setup(void)
phys_bits = eax & 0xff;
}
u64 phys_mask = ((1ull << phys_bits) - 1);
+for (i=0; ihttp://vger.kernel.org/majordomo-info.html
Re: migration and snapshots.
On Wed, Dec 30, 2009 at 10:55:34AM -0800, J Nb wrote: > What would be a good storage topology for allowing for migration as well as > support snapshots (for backup) > > Would love to hear recommendations as well as details on setup that people > are using. (I am assuming that this is possible.) > > Here is my current understanding.. > > LVM -- Snapshots but not shared. > CLVM -- shared but no snapshots. (yet) > NFS/GFS -- Shared FS but no snapshots > > > qcow2 files and VHD file supports snapshots... but VHD is not yet available > in Xen or KVM. > blktap2 backend in Xen supports VHD. See: http://markmail.org/message/dqcil5uyigwlk2sr -- Pasi -- 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: Memory usage with qemu-kvm-0.12.1.1
Hi, Hugh. On Thursday, 31 December 2009 17:02:49 +, Hugh Dickins wrote: > On Thu, 31 Dec 2009, Daniel Bareiro wrote: > > > > What tests would be recommendable to make to reproduce the problem? > > Oh, I thought you were the one seeing the problem! If you cannot > easily reproduce it, then please don't spend too long over it. > > I've never noticed it myself (perhaps because my workaday loads are > too light, and my testing loads too heavy): I was just judging by > the content of Rik's patch. Rik cites AIM7 in his description, > but perhaps someone knows an easier way to demonstrate it; though > I was more interested in whether it also fixes the problem you saw. Well... after of compiling three times the kernel 2.6.32.2 to test, having the same running VMs, the swap usage reached 40% from 0%. Can it be taken like as an evidence that the problem was reproduced? r...@ubuntu:~# free total used free sharedbuffers cached Mem: 40603403927632 132708 0 837042265672 -/+ buffers/cache:15782562482084 Swap: 497972 202944 295028 > > You say that the patch applies and builds correctly on 2.6.31.9 and > > 2.6.32.3. I would like to test it with 2.6.32.3, but I didn't find the > > source code of it in [1]. It would have to be in another path? > > Umm, may I pretend that, as we approach the New Year, I was gazing > into my crystal ball? Or should I just admit to a stupid typo? > Such a dilemma, but I'll go for honesty: 2.6.32.2, sorry about that! I thought maybe 2.6.32.3 was some development version and that is why I chose to ask. Although I thought that it would be a typo. Don't worry :-) > > Thanks for your reply and the patch. > > Thanks go to Rik for the patch. And thanks for your report and > testing, but please don't put yourself out over it: the patch > already looks good, and I think it should go to -stable with > or without the commendation of whether it works for you. Also I was doing the same amount of compilations with the 2.6.32.2 with Rik's patch and the amount of used swap is substantially lower: r...@ubuntu:~# free total used free sharedbuffers cached Mem: 40603403956872 103468 0 809122689772 -/+ buffers/cache:11861882874152 Swap: 497972 8152 489820 From Buenos Aires I wish you a happy new year!! Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature
How does the network packed in guest os deliver to the host?
Does it make use of the kvm exit handler? Where the detailed code involved about the kvm's control? Any tips? Thks. -- 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
