[ kvm-Bugs-1842160 ] Solaris 10 8/07 (AKA update 4) x86 guest can't boot 64 bit
Bugs item #1842160, was opened at 2007-11-30 21:12 Message generated for change (Comment added) made by carenas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1842160&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: intel Group: None Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Carlo Marcelo Arenas Belon (carenas) Assigned to: Amit Shah (amitshah) Summary: Solaris 10 8/07 (AKA update 4) x86 guest can't boot 64 bit Initial Comment: Host CPU: Intel(R) Core(TM)2 CPU 6320 KVM: 54 + ide patches and set_cr3 patch pre-kvm-55 Host OS: Gentoo 2007.0 with kernel 2.6.22-gentoo-r9 Host ARCH: amd64 (64bit) Guest OS: Solaris 10 8/07 x86 Generic 120012-14 VM parameters: -m 512 problem only happens when running kvm's CPU emulation (doesn't happen with -no-kvm) and triggers a GP as shown by : set_cr4: #GP, clearing PAE while in long mode inject_general_protection: rip 0x100ee24. it might be related to the GP reported as part of the discussion for bug 1699695 which apparently has a patch available (but not yet committed) which I hadn't been able to track down to test -- >Comment By: Carlo Marcelo Arenas Belon (carenas) Date: 2008-07-12 23:18 Message: Logged In: YES user_id=36771 Originator: YES This still affects the last update (u5) of Solaris 10 (5/08) but interestingly enough does not affect OpenSolaris versions based in nevada b85 (OpenSolaris 2008.05 or Nexenta Core 2.0 alpha 1) -- Comment By: Amit Shah (amitshah) Date: 2008-03-04 04:08 Message: Logged In: YES user_id=201894 Originator: NO Looks like we'll have to wait more. windows 64-bit doesn't like this change. -- Comment By: Amit Shah (amitshah) Date: 2008-03-03 22:13 Message: Logged In: YES user_id=201894 Originator: NO Fix is in kvm-git. Will be part of kvm-63. -- Comment By: Carlo Marcelo Arenas Belon (carenas) Date: 2007-12-01 01:02 Message: Logged In: YES user_id=36771 Originator: YES there was a bug in the way I disabled the GP for set_cr4 which triggered the set_cr0, so that is not a real issue. the suggested patch fixes the problem (using an Intel Host as well as it does most likely for AMD hosts as reported in the thread). will leave bug open for now, to help for follow up into committing this patch and release -- Comment By: Amit Shah (amitshah) Date: 2007-12-01 00:12 Message: Logged In: YES user_id=201894 Originator: NO Use the patch in http://www.mail-archive.com/kvm-devel%40lists.sourceforge.net/msg08947.html to resolve the #gp -- Comment By: Carlo Marcelo Arenas Belon (carenas) Date: 2007-11-30 23:20 Message: Logged In: YES user_id=36771 Originator: YES if LME/LMA handling is considered buggy as reported in BUG 1699695 and the GP commented out, another GP is generated after as shown by : BUG: set_cr4: #GP, clearing PAE while in long mode set_cr0: #GP, pdptrs reserved bits inject_general_protection: rip 0x100ee49 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1842160&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sharing variables/memory between host and guest ?
On Sat, Jul 12, 2008 at 4:59 PM, Arn <[EMAIL PROTECTED]> wrote: > Eric, thanks for the prompt response, a few more questions: > >> The virtio portions of the kernel were just added in 2.6.24, the >> server portion has not yet been integrated into the kvm-qemu mainline, >> but is fairly trivial to merge. You can also use the TCP/IP version >> of the 9p transport to get access to synthetic file systems until all >> the virtio stuff gets merged. > > What exactly is "kvm-qemu mainline" ? Is it the qemu parts of KVM that > have been merged into the kernel ? Could you point to which directory > of the kernel code this refers to (also kernel version) ? > I'm talking about the kvm-userspace pieces, not kernel pieces. -eric -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sharing variables/memory between host and guest ?
Eric, thanks for the prompt response, a few more questions: > The virtio portions of the kernel were just added in 2.6.24, the > server portion has not yet been integrated into the kvm-qemu mainline, > but is fairly trivial to merge. You can also use the TCP/IP version > of the 9p transport to get access to synthetic file systems until all > the virtio stuff gets merged. What exactly is "kvm-qemu mainline" ? Is it the qemu parts of KVM that have been merged into the kernel ? Could you point to which directory of the kernel code this refers to (also kernel version) ? Also would this be a fast way to share a few variables between guest and host ? > If you really want to stick with the 2.6.22 kernel, it may be possible > to build 9p modules with the back ported virtio changes (in fact we > were doing just that for a bit). No, I can upgrade my kernel. I just need to know which one I should use. Should I just go with the latest stable 2.6.25.10 kernel with kvm-70 module ? Thanks arn -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sharing variables/memory between host and guest ?
On Sat, Jul 12, 2008 at 4:03 PM, Arn <[EMAIL PROTECTED]> wrote: >> >> A paravirtualized driver can take care of that with driver in the guest and >> device side in qemu/host kernel. >> You can use 9p virtio solution in Linux that implements a shared file >> system. > > I had a look at the 9p related slides on the KVMForum 2008 page on the > wiki and it may serve my purpose but I need to investigate more. > > According to the slides 9p has been in Linux since 2.6.14 . I'm > currently using linux kernel 2.6.22-14 (ubuntu 7.10) with a downloaded > kvm-70 . Is this enough for using 9p with KVM or do i need a newer > linux kernel ? > The virtio portions of the kernel were just added in 2.6.24, the server portion has not yet been integrated into the kvm-qemu mainline, but is fairly trivial to merge. You can also use the TCP/IP version of the 9p transport to get access to synthetic file systems until all the virtio stuff gets merged. If you really want to stick with the 2.6.22 kernel, it may be possible to build 9p modules with the back ported virtio changes (in fact we were doing just that for a bit). -eric -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sharing variables/memory between host and guest ?
Thanks Dor. More below. >> How can one share memory (a few variables not necessarily a page) >> between host/hypervisor and guest VM ? >> Since the guest is just a process within the host, there should be >> existing ways to do this. >> > It's not that straight forward since the host has its pfn (page frame > number) while the guest has gfn (guest frame number) and also use virtual > memory. So does this mean that there is no way to share a page between host and guest like can be done in Xen ? Wouldn't such a feature be useful ? > >> What about using something like debugfs or sysfs, is it possible to >> share variables this way ? Note, I want a system that >> is fast, i.e. changes to shared variable/memory should be visible >> instantly. > > A paravirtualized driver can take care of that with driver in the guest and > device side in qemu/host kernel. > You can use 9p virtio solution in Linux that implements a shared file > system. I had a look at the 9p related slides on the KVMForum 2008 page on the wiki and it may serve my purpose but I need to investigate more. According to the slides 9p has been in Linux since 2.6.14 . I'm currently using linux kernel 2.6.22-14 (ubuntu 7.10) with a downloaded kvm-70 . Is this enough for using 9p with KVM or do i need a newer linux kernel ? While on this topic I'd like to point out that its a bit difficult to understand which version of kvm maps to which linux kernel. The page on the wiki is dated. Is it ok to use a kvm-70 module with a slightly older linux kernel ? thanks for you help arn -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM, SCSI & OpenSolaris
On 12/07/2008, at 12:15 AM, Thomas Mueller wrote: On Thu, 10 Jul 2008 15:50:41 -0500, Anthony Liguori wrote: I don't quite following what you are saying. Are you saying that OpenSolaris no longer supports the SCSI card we emulate? That seems unfortunate on their part. I would also be surprised by that since the same SCSI implementation is used by Xen and Sun is heavily invested in OpenSolaris for Xen at this point. i can also confirm that OpenSolaris 2008.05 AMD64 says "Driver missing!" for the Qemu (LSI Logic 53c895a) SCSI card. - Thomas I did some more digging. The symhisl driver definitely seems to have been dropped from OpenSolaris 64bit versions. See this post: http://osdir.com/ml/os.solaris.solarisx86/2004-12/msg00179.html While this isn't "official" looking it fits with the evidence i.e. the symhisl driver seems to be no more in the 64bit world. Anyway the point being this effects the following scsi chipsets: LSI Logic SYM53C895A, SYM53C1010-33, and SYM53C1010-66 SCSI I/O processors where QEMU/KVM emulates the SYM53C895A (as I understand it) The glm driver is still distributed. This driver supports the following scsi chipsets: LSI 53c810, LSI 53c875, LSI 53c876, LSI 53c896 and LSI 53c1010 SCSI I/ O processors VMWare supports the 53c1010 so it is fine with scsi images/drives under OpenSolaris Conclusion: Since this was all driven by my interest in ZFS my wrap up comes from that angle: As it stands if you want to experiment with ZFS using OpenSolaris under KVM you need to use IDE which means you can only play with up to 4 disks. Enough for PoC work. If you want to use KVM to run an OpenSolaris VM that directly manages 4+ physical disks plus a boot img then you are probably stumped as KVM's scsi isn't supported under OpenSolaris or its derivatives like Nexus. Plus 4 IDE devices will not give you the 5+ devices you need. I have tried the FreeBSD7 path and while I can get scsi working, the ZFS implementation in that OS is so new it seems to be pretty fragile. I can consistently get it to die (i.e. KVM seg faults) under either scsi or ide disks, and I have tuned ZFS a number of ways per instructions. On the plus side I have been running 6 Ubuntu JEOS VMs under KVM for a wee while now and it is working VERY VERY well. I continue to resist moving to VMWare. :-) As always if some kind soul can show I have missed a trick please let me know. I am still rather keen on getting that ZFS NAS working. I just can't justify buying new/more h/w to do it. Cheers, James. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm guest loops_per_jiffy miscalibration under host load
Marcelo Tosatti wrote: > Hi David, > > On Fri, Jul 11, 2008 at 03:18:54PM -0600, David S. Ahern wrote: >> What's the status with this for full virt guests? > > The consensus seems to be that fullvirt guests need assistance from the > management app (libvirt) to have boosted priority during their boot > stage, so loops_per_jiffy calibration can be performed safely. As Daniel > pointed out this is tricky because you can't know for sure how long the > boot up will take, if for example PXE is used. I boosted the priority of the guest to investigate an idea that maybe some startup calibration in the guest was off slightly leading to systematic drifting. I was on vacation last week and I am still catching up with traffic on this list. I just happened to see your first message with the panic which aligned with one of my tests. > > Glauber is working on some paravirt patches to remedy the situation. > > But loops_per_jiffy is not directly related to clock drifts, so this > is a separate problem. > >> I am still seeing systematic time drifts in RHEL 3 and RHEL4 guests >> which I've been digging into it the past few days. > > All time drift issues we were aware of are fixed in kvm-70. Can you > please provide more details on how you see the time drifting with > RHEL3/4 guests? It slowly but continually drifts or there are large > drifts at once? Are they using TSC or ACPIPM as clocksource? The attached file shows one example of the drift I am seeing. It's for a 4-way RHEL3 guest started with 'nice -20'. After startup each vcpu was pinned to a physical cpu using taskset. The only activity on the host is this one single guest; the guest is relatively idle -- about 4% activity (~1% user, ~3% system time). Host is synchronized to an ntp server; the guest is not. The guest is started with the -localtime parameter. From the file you can see the guest gains about 1-2 seconds every 5 minutes. Since it's a RHEL3 guest I believe the PIT is the only choice (how to confirm?), though it does read the TSC (ie., use_tsc is 1). > > Also, most issues we've seen could only be replicated with dyntick > guests. > > I'll try to reproduce it locally. > >> In the course of it I have been launching guests with boosted priority >> (both nice -20 and realtime priority (RR 1)) on a nearly 100% idle >> host. > > Can you also see wacked bogomips without boosting the guest priority? The wacked bogomips only shows up when started with real-time priority. With the 'nice -20' it's sane and close to what the host shows. As another data point I restarted the RHEL3 guest using the -no-kvm-pit and -tdf options (nice -20 priority boost). After 22 hours of uptime, the guest is 29 seconds *behind* the host. Using the in-kernel pit the guest time is always fast compared to the host. I've seen similar drifting in RHEL4 guests, but I have not spent as much time investigating it yet. On ESX adding clock=pit to the boot parameters for RHEL4 guests helps immensely. david host-dt host timeguest timeguest-host-diff 300 1215748151 1215748262111 301 1215748452 1215748563111 300 1215748752 1215748865113 300 1215749052 1215749165113 300 1215749352 1215749466114 301 1215749653 1215749768115 300 1215749953 1215750069116 300 1215750253 1215750369116 300 1215750553 1215750671118 301 1215750854 1215750972118 300 1215751154 1215751273119 300 1215751454 1215751575121 300 1215751754 1215751875121 301 1215752055 1215752176121 300 1215752355 1215752477122 300 1215752655 1215752780125 300 1215752955 1215753083128 301 1215753256 1215753385129 300 1215753556 1215753686130 300 1215753856 1215753988132 300 1215754156 1215754289133 301 1215754457 1215754592135 300 1215754757 1215754894137 300 1215755057 1215755198141 300 1215755357 1215755499142 301 1215755658 1215755799141 300 1215755958 1215756101143 300 1215756258 1215756402144 300 1215756558 1215756702144 301 1215756859 1215757005146 300 1215757159 1215757307148 300 1215757459 1215757609150 301 1215757760 1215757910150 300 1215758060 1215758211151 300 1215758360 1215758515155 300 1215758660 1215758816156 301 1215758961 1215759118157 300 1215759261 1215759418157 300 1215759561 1215759720159 300 1215759861 1215760022161 301 1215760162 1215760323161 300 1215760462 1215760625163 300 1215760762 1215760927165 300 1215761062 1215761229167 301 1215761363 1215761532169 300 1215761663 1215761833170 300 1215761963 1215762136173 300 1215762263 1215
Re: [RFC][PATCH] Add HPET emulation to qemu
Hi Beth,
On Jul 10, 2008, at 5:48 AM, Beth Kon wrote:
This patch, based on an earlier patch by Alexander Graf, adds HPET
emulation to qemu. I am sending out a separate patch to kvm with the
required bios changes.
This work is incomplete.
Wow it's good to see that someone's working on it. I am pretty sure
that you're basing on an older version of my HPET emulation, so you
might also want to take a look at the current patch file residing in http://alex.csgraf.de/qemu/osxpatches.tar.bz2
Currently working (at least generally):
- linux 2.6.25.9 guest
Todo:
- other guest support (i.e. adding whatever may be missing for
support of other modes of operation used by other OS's).
- level-triggered interrupts
Look at my current version for that. I only have Level support in
there for now though.
- non-legacy routing
- 64-bit operation
- ...
While reading through the code I realized how badly commented it is.
At least the functions should have some comments on them what their
purpose is.
Furthermore there still are a lot of magic numbers in the code. While
that is "normal qemu code style" and I wrote it this way, I'm not too
fond of it. So it might be a good idea to at least make the switch
numbers defines.
Basically what I've done so far is make it work for linux.
The one area that feels ugly/wrong at the moment is handling the
disabling of 8254 and RTC timer interrupts when operating in legacy
mode. The HPET spec says "in this case the 8254/RTC timer will not
cause
any interrupts". I'm not sure if I should disable the RTC/8254 in some
more general way, or just disable interrupts. Comments appreciated.
IIRC the spec defines that the HPET _can_ replace the 8254, but does
not have to. So you should be mostly fine on that part.
Signed-off-by: Beth Kon <[EMAIL PROTECTED]>
diffstat output:
Makefile.target |2
hw/hpet.c| 393
+++
hw/i8254.c |8 -
hw/mc146818rtc.c | 25 ++-
hw/pc.c |5
5 files changed, 427 insertions(+), 6 deletions(-)
diff --git a/Makefile.target b/Makefile.target
index 73adbb1..05829ea 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -530,7 +530,7 @@ ifeq ($(TARGET_BASE_ARCH), i386)
OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
-OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o
+OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o hpet.o
CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
endif
ifeq ($(TARGET_BASE_ARCH), ppc)
diff --git a/hw/hpet.c b/hw/hpet.c
new file mode 100644
index 000..e74de08
--- /dev/null
+++ b/hw/hpet.c
@@ -0,0 +1,393 @@
+/*
+ * High Precisition Event Timer emulation
+ *
+ * Copyright (c) 2007 Alexander Graf
+ * Copyright (c) 2008 IBM Corporation
+ *
+ * Authors: Beth Kon <[EMAIL PROTECTED]>
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free
Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307
USA
+ *
+ * *
+ *
+ * This driver attempts to emulate an HPET device in software. It
is by
no
+ * means complete and is prone to break on certain conditions.
+ *
+ */
+#include "hw.h"
+#include "console.h"
+#include "qemu-timer.h"
+
+//#define HPET_DEBUG
+
+#define HPET_BASE 0xfed0
This is a dirty hack that I did to make Mac OS X happy. Actually the
HPET base address gets specified in the RCBA on the LPC and is
configured by the BIOS to point to a valid address, with 0xfed0
being the default (IIRC if you write 0 to the fields you end up with
that address).
+#define HPET_PERIOD 0x00989680 /* 1000 femptoseconds,
10ns*/
Any reason why this is a hex value? I find 1000 a lot easier to
read :-)
+
+#define FS_PER_NS 100
+#define HPET_NUM_TIMERS 3
+#define HPET_TIMER_TYPE_LEVEL 1
+#define HPET_TIMER_TYPE_EDGE 0
+#define HPET_TIMER_DELIVERY_APIC 0
+#define HPET_TIMER_DELIVERY_FSB 1
+#define HPET_TIMER_CAP_FSB_INT_DEL (1 << 15)
+#define HPET_TIMER_CAP_PER_INT (1 << 4)
+
+struct HPETState;
+typedef struct HPETTimer {
+QEMUTimer *timer;
+struct HPETState *state;
+uint8_t type;
+uint8_t active;
+uint8_t delivery;
+uint8_t apic_port;
+uint8_t p
Re: [ANNOUNCE] kvm-autotest
* Uri Lublin <[EMAIL PROTECTED]> [2008-07-10 07:42]:
> Marcelo Tosatti wrote:
> >On Sun, Jul 06, 2008 at 01:16:13PM +0300, Uri Lublin wrote:
> >>
> >>The test framework is based on autotest (
> >>http://test.kernel.org/autotest ).
> >>Currently we only using client tests, later we may want to use server
> >>tests
> >>for more complicated tests.
> >
> >This is looking great. Easy to use and fast. A few comments:
> >
> >- As you mention, it should reuse the server/client model for running
> > tests inside guests. I hacked up a "kvm_autotest" test that
> > basically does:
> >
> >tests = ["linus_stress", "bash_shared_mapping", "rmaptest", "tsc",
> >"scrashme", "isic", "sleeptest", "libhugetlbfs", "..."]
> >
> >vm.ssh.scp_to_remote(autotest_tarball, '/root')
> >(s,o) = vm.ssh.ssh('tar zvxf kvm-autotest.tar.gz')
> >for i in range(0, len(tests)):
> >(s,o) = vm.ssh.ssh('kvm-autotest/client/bin/autotest ' +
> > 'kvm-autotest/client/tests/' + tests[i] +
> > '/control')
> >print(o)
> >
> >Which poorly replicates what the client/server infrastructure already
> >provides. IMO its a waste of time to write specialized client
> >tests (other than virt specific ones).
> >
>
> You see guests as clients and the host as the server.
> We were thinking of the host as a client and multi-host operations to be
> done by a server. guest-operations would be done using ssh (for linux
> guests) as your example above. You make a good point that we can use
> server/client infrastructure for guest operations. As it is simpler to
> write autotest client tests, and we thought most of the tests would be run
> as client tests, we want to postpone the server tests and focus on adding
> tests and guests to the matrix.
It's definitely worth looking at the autotest server code/samples.
There exists code in-tree already to build an deploy kvm via autotest
server mode which a single machine can drive the building, installing,
creation of guests on N number of clients, directing each guest
image to run various autotest client tests, collecting all of the
results.
See autotest/server/samples/*kvm*
A proper server setup is a little involved[1] but much more streamlined
these days.
> You probably do not need to change the migration test. I think we need to
> run some load on the guest (we'd probably have many load options, and the
> user will choose/configure which one to use) before migration starts and
> keep it running during the migration process.
>
> >
> >- Currently its difficult to debug client test failure inside guests,
> > since the VM and its image are destroyed. Perhaps the client/server
> > model handles error handling/reporting much more nicely.
>
> Agreed, we thought of that, but it's not cooked yet. Currently we always
> cleanup. We should not remove the (temporary) image if the test fails.
> Should we keep the guest running upon failure ? Currently we continue to
> test the next guest. We should probably have a configuration flag for that
> too.
I suppose it depends on the failure, if we're capturing the boot log
then for boot failures, I don't see any reason to keep running. If we
succeed in booting but fail at some further point, then I think it makes
sense to keep them running.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl8139 stop working under high load
Dor Laor wrote: Farkas Levente wrote: hi, i'm just switch to the use rtl8139 network emulator in kvm-70 for the guests, but under high load it's simple stop working. a reboot or even a service network restart solve the problem, but imho there should have to be some bug in the qemu's rtl8139 code. and there is not any kind of error in any log (neither the host's nor the guest's). this not happened with e1000. but with e1000 the network sometimes seems to breathing (sometimes slow down and then speed up again). do currently which is the preferred network network device in qemu/kvm? thanks. I think rtl8139 is the most stable, and afterwards virtio and e1000 (which both perform much better too). Maybe it's irq problem. Can you run the same test with -no-kvm-irqchip ? it happened when i run revisor to build iso through an nsf mounted volume (where the nefs server was another kvm guest). i try 4 times with rtl8139 and it always stop working. when i switch back to e1000 then this not happened. i can't test it now remotely:-( -- Levente "Si vis pacem para bellum!" -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-autotest
Hi Uri, On Thu, Jul 10, 2008 at 03:09:36PM +0300, Uri Lublin wrote: > You see guests as clients and the host as the server. > We were thinking of the host as a client and multi-host operations to be > done by a server. guest-operations would be done using ssh (for linux > guests) as your example above. You make a good point that we can use > server/client infrastructure for guest operations. As it is simpler to > write autotest client tests, and we thought most of the tests would be > run as client tests, we want to postpone the server tests and focus on > adding tests and guests to the matrix. Perhaps you need a main server on top for that, to coordinate various hosts. The big problem with writing client tests is that you have to rewrite what autotest already provides, diverging from mainline. That means work to be done everytime a new test is added in autotest, which could come for free if guests were treated as clients and the host treated as a server. And the other way around is also true: new OS tests added to kvm-autotest will not make their way naturally into autotest mainline. Other than Windows tests, of course, but most Linux OS tests should run fine in *NIX. >> - On top of the client tests, we want to be able to force "special >> stress conditions", such as: >> - host memory pressure (to test mmu shrink and mmu notifiers) > Similar is how many guests (or what to memory over-subscription > percentage) we can start while all of them are responsive. >> - CPU starvation (lower the priority of the guest process with >> higher prio CPU hungry tasks running on the host). >> - synthetic cpu migration stress. ChrisW wrote this script sometime >> ago to test clock stability: >> >> PID=$1 >> while : >> do >> for x in 0x01 0x02 0x04 0x08 0x10 0x20 0x40 0x80 >> do >> taskset -p $x $PID > /dev/null 2>&1 >> usleep 5 >> done >> done >> - migration (as it stands now there is no transparent way to >> schedule client tests to run _while_ migration is in progress, >> one needs to >> manually change the migration test for that). > > You probably do not need to change the migration test. I think we need to > run some load on the guest (we'd probably have many load options, and the > user will choose/configure which one to use) before migration starts and > keep it running during the migration process. Right. >> - Currently its difficult to debug client test failure inside guests, >> since the VM and its image are destroyed. Perhaps the client/server >> model handles error handling/reporting much more nicely. > > Agreed, we thought of that, but it's not cooked yet. Currently we always > cleanup. We should not remove the (temporary) image if the test fails. > Should we keep the guest running upon failure ? Currently we continue to > test the next guest. We should probably have a configuration flag for > that too. Yes, it should be dependant on a configuration flag. For developer use, stopping the run makes sense so the failure can be analyzed. For stress/coverage, you want to know results of the entire test battery. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm guest loops_per_jiffy miscalibration under host load
Hi David, On Fri, Jul 11, 2008 at 03:18:54PM -0600, David S. Ahern wrote: > What's the status with this for full virt guests? The consensus seems to be that fullvirt guests need assistance from the management app (libvirt) to have boosted priority during their boot stage, so loops_per_jiffy calibration can be performed safely. As Daniel pointed out this is tricky because you can't know for sure how long the boot up will take, if for example PXE is used. Glauber is working on some paravirt patches to remedy the situation. But loops_per_jiffy is not directly related to clock drifts, so this is a separate problem. > I am still seeing systematic time drifts in RHEL 3 and RHEL4 guests > which I've been digging into it the past few days. All time drift issues we were aware of are fixed in kvm-70. Can you please provide more details on how you see the time drifting with RHEL3/4 guests? It slowly but continually drifts or there are large drifts at once? Are they using TSC or ACPIPM as clocksource? Also, most issues we've seen could only be replicated with dyntick guests. I'll try to reproduce it locally. > In the course of it I have been launching guests with boosted priority > (both nice -20 and realtime priority (RR 1)) on a nearly 100% idle > host. Can you also see wacked bogomips without boosting the guest priority? > > One host is a PowerEdge 2950 running RHEL5.2 with kvm-70. > With the realtime priority boot I have routinely seen bogomips in the > guest which do not make sense. e.g., > > ksyms.2:bogomips: 4639.94 > ksyms.2:bogomips: 4653.05 > ksyms.2:bogomips: 4653.05 > ksyms.2:bogomips: 24.52 > > and > > ksyms.3:bogomips: 4639.94 > ksyms.3:bogomips: 4653.05 > ksyms.3:bogomips: 16.33 > ksyms.3:bogomips: 12.87 I'll look into it. > > > Also, if I launch qemu with the "-no-kvm-pit -tdf" option the panic > guests panics with the message Marcelo posted at the start of the thread: > > > > Calibrating delay loop... 4653.05 BogoMIPS > > CPU: L2 cache: 2048K > > Intel machine check reporting enabled on CPU#2. > > CPU2: Intel QEMU Virtual CPU version 0.9.1 stepping 03 > > Booting processor 3/3 eip 2000 > > Initializing CPU#3 > > masked ExtINT on CPU#3 > > ESR value before enabling vector: > > ESR value after enabling vector: > > Calibrating delay loop... 19.60 BogoMIPS > > CPU: L2 cache: 2048K > > Intel machine check reporting enabled on CPU#3. > > CPU3: Intel QEMU Virtual CPU version 0.9.1 stepping 03 > > Total of 4 processors activated (14031.20 BogoMIPS). > > ENABLING IO-APIC IRQs > > Setting 4 in the phys_id_present_map > ...changing IO-APIC physical APIC ID to 4 ... ok. > ..TIMER: vector=0x31 pin1=0 pin2=-1 > ..MP-BIOS bug: 8254 timer not connected to IO-APIC > ...trying to set up timer (IRQ0) through the 8259A ... failed. > ...trying to set up timer as Virtual Wire IRQ... failed. > ...trying to set up timer as ExtINT IRQ... failed :(. > Kernel panic: IO-APIC + timer doesn't work! pester [EMAIL PROTECTED] > > > > I'm just looking for stable guest times. I'm not planning to keep the > boosted guest priority, just using it to ensure the guest is not > interrupted as I try to understand why the guest systematically drifts. > > david -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] VMX: Remove redundant check in handle_rmode_exception
Since checking for vcpu->arch.rmode.active is already done whenever we
call handle_rmode_exception(), checking it inside the function is redundant.
Signed-off-by: Mohammed Gamal <[EMAIL PROTECTED]>
---
arch/x86/kvm/vmx.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6145dbd..f6de4c6 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2225,9 +2225,6 @@ static void kvm_guest_debug_pre(struct kvm_vcpu *vcpu)
static int handle_rmode_exception(struct kvm_vcpu *vcpu,
int vec, u32 err_code)
{
- if (!vcpu->arch.rmode.active)
- return 0;
-
/*
* Instruction with address size override prefix opcode 0x67
* Cause the #SS fault with 0 error code in VM86 mode.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl8139 stop working under high load
Farkas Levente wrote: hi, i'm just switch to the use rtl8139 network emulator in kvm-70 for the guests, but under high load it's simple stop working. a reboot or even a service network restart solve the problem, but imho there should have to be some bug in the qemu's rtl8139 code. and there is not any kind of error in any log (neither the host's nor the guest's). this not happened with e1000. but with e1000 the network sometimes seems to breathing (sometimes slow down and then speed up again). do currently which is the preferred network network device in qemu/kvm? thanks. I think rtl8139 is the most stable, and afterwards virtio and e1000 (which both perform much better too). Maybe it's irq problem. Can you run the same test with -no-kvm-irqchip ? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sharing variables/memory between host and guest ?
Arn wrote: How can one share memory (a few variables not necessarily a page) between host/hypervisor and guest VM ? Since the guest is just a process within the host, there should be existing ways to do this. It's not that straight forward since the host has its pfn (page frame number) while the guest has gfn (guest frame number) and also use virtual memory. What about using something like debugfs or sysfs, is it possible to share variables this way ? Note, I want a system that is fast, i.e. changes to shared variable/memory should be visible instantly. A paravirtualized driver can take care of that with driver in the guest and device side in qemu/host kernel. You can use 9p virtio solution in Linux that implements a shared file system. I search the kvm-devel archives and found emails referring to "kshmem" but a search on the kvm-70 code turns up nothing. There are also some emails on sharing a page but no final outcome or what exactly to do. Thanks Arn -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Forward DB# exceptions to real mode guests
From: Jan Kiszka <[EMAIL PROTECTED]>
This fixes the issue booting FreeDOS under userspace kvm-70rc1 and
above.
Signed-off-by: Mohammed Gamal <[EMAIL PROTECTED]>
---
arch/x86/kvm/vmx.c | 12
include/asm-x86/kvm_host.h |1 +
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index f998943..6145dbd 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2235,6 +2235,18 @@ static int handle_rmode_exception(struct kvm_vcpu *vcpu,
if (((vec == GP_VECTOR) || (vec == SS_VECTOR)) && err_code == 0)
if (emulate_instruction(vcpu, NULL, 0, 0, 0) == EMULATE_DONE)
return 1;
+
+ /*
+* Forward #DB to host, this is required to boot FreeDOS
+*
+* FIXME: Quick-hack, breaks guest debugging in real mode, will be
+* fixed with the required debugging infrastructure rework.
+*/
+ if (vec == DB_VECTOR) {
+ vmx_inject_irq(vcpu, vec);
+ return 1;
+ }
+
return 0;
}
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 82237b2..aad6244 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -56,6 +56,7 @@
#define KVM_PAGES_PER_HPAGE (KVM_HPAGE_SIZE / PAGE_SIZE)
#define DE_VECTOR 0
+#define DB_VECTOR 1
#define UD_VECTOR 6
#define NM_VECTOR 7
#define DF_VECTOR 8
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Regression] kvm-userspace: VM freezes after booting FreeDOS
Mohammed Gamal wrote:
> On Fri, Jul 11, 2008 at 1:53 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
>> Mohammed Gamal wrote:
>>> On Fri, Jul 11, 2008 at 12:22 AM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Mohammed Gamal wrote:
> On Thu, Jul 10, 2008 at 11:02 PM, Anthony Liguori <[EMAIL PROTECTED]>
> wrote:
>> Mohammed Gamal wrote:
>>> On Thu, Jul 10, 2008 at 7:31 PM, Anthony Liguori <[EMAIL PROTECTED]>
>>> wrote:
>>>
Mohammed Gamal wrote:
> After updating my kvm-userspace tree to the latest git tree. I am no
> more able to run FreeDOS. The VM freezes after choosing any of the
> boot options. I am running both latest kvm.git and kvm-userspace.git
>>>
>>>
> After booting FreeDOS, there are a number of boot options with
> different memory extenders, after selecting any option the system
> freezes and I get [Stopped] in thr QEMU title bar.
"Stopped" - interesting. Seems like something causes QEMU to stop the
guest as if some breakpoint was injected.
I just downloaded that image and gave it a try against vanilla kvm-70
and my own tree which is augment with guest debugging related patches.
The former shows your observed behavior (Boot from CD, provide an empty
HD image -> press '1' + ENTER -> press '1' -> "Stopped"). The latter kvm
tree made QEMU leave with a #GP in the guest. That may point to a debug
register related issue, and that patch you identified just happen to
make it visible. However, will try to investigate.
Jan
>>> I'm interested in seeing these patches. If your tree is hosted online,
>>> could you please provide me with its location so that I can merge it
>>> with mine. If not, where can I get them from?
>> Find both attached. They are a rebase of the kernel side (subset) from
>> my earlier posted debug rework series. They apply against latest kvm
>> kernel git in this order:
>>
>> 1. kvm-new-guest-debug-interface-v2.patch
>> 2. kvm-x86-virtualize-debug-registers-v2.patch
>>
>> The first one makes no difference, but the second one changes the
>> behavior from reporting a breakpoint to userland to reporting an exception.
>>
>
> Thanks for sending.
>
>> I haven't found enough time to dig into this yet, but my gut feeling so
>> far is that some x86 real mode emulation issue is biting us. Debug
>> registers are not involved, I've cross-checked with enhanced QEMU
>> supporting that feature - no invocation of related helper functions there.
>>
>
> I still think it might be an issue with debug exceptions. I did get a
> #GP after applying your patches.
>
> Analyizng the output I observed a few things:
> - rflags has TF, IF, DF, RF, and of course VM set and IOPL = 3. Do we
Yes, we have TF set (I checked for this initially as well, but I starred
at the wrong nibble). Here is the related code from himem.exe
(himem64.asm [1]):
> ;**
> ; 16-bit transient code and data. only used once.
> ;**
> ; checks if CPU is a 386
> ; In: nothing
> ; Out: CY=0 - processor is a 386 or higher
> ; CY=1 - processor lower than 386
>
> proccheck_cpu
> pushf
> xor ax,ax
> pushax
> popf
> pushf
> pop ax
> and ah,0fh
> cmp ah,0fh
> je not386
> mov ah,7
> pushax
> popf
> pushf
Here we crash (with my patch) or report a break to the host (vanilla)
instead of delivering a #DB trap to the guest.
> pop ax
> and ah,7
> je not386
> popf
> clc
> ret
> not386:
> popf
> stc
> ret
> endpcheck_cpu
> handle interrupts while being aware that single-stepping takes a
> higher priority over all other external interrupts? May be some
> interrupt was injected while TF was set and we try to serve that
> interrupt first? If yes, would that cause a #GP?
>
> - The #GP pushed error code b . CIIW, but doesn't this mean it was
> caused by a #DB exception (bits EXT = 1, IDT = 1, with IDT vector 1
> which is a debug exception) .
It looks like that we should forward all #DB exceptions to the guest in
real mode unless we are sure they were caused by a host-injection. Here
is more or less a hack to achieve this (breaking guest debugging for
now):
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index b60fcec..a6f9c9b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2244,6 +2244,15 @@ static int handle_rmode_exception(struct kvm_vcpu *vcpu,
if (((vec == GP_VECTOR) || (vec == SS_VECTOR)) && err_code == 0)
if (emulate_instruction(vcpu, NULL, 0, 0, 0) == EMULATE_DONE)
return 1;
+ /*
+* Forward #DB
+* FIXME: Quick-hack, breaks guest debugging in real mode, will be
+*fixed with the required debugging infrastructure rework.
+*/
+ if (vec == 1) {
+
