Menu
▾
▴
kvm-devel — kernel virtual machine development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(33) |
Nov
(325) |
Dec
(320) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(484) |
Feb
(438) |
Mar
(407) |
Apr
(713) |
May
(831) |
Jun
(806) |
Jul
(1023) |
Aug
(1184) |
Sep
(1118) |
Oct
(1461) |
Nov
(1224) |
Dec
(1042) |
| 2008 |
Jan
(1449) |
Feb
(1110) |
Mar
(1428) |
Apr
(1643) |
May
(682) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Anthony L. <an...@co...> - 2008-05-05 12:57:06
|
Guillaume Thouvenin wrote: > On Sat, 3 May 2008 13:56:56 +0530 > Balaji Rao <bal...@gm...> wrote: > > > >> With your patch applied ubuntu 8.04 livecd fails to boot. Not any better >> with Marcelo's patch on top. >> > > Hi Balaji, > > And without the patch, can you boot the ubuntu 8.04 livecd? > WinXP fails to boot with your patch applied too. FWIW, Ubuntu 8.04 has a fixed version of gfxboot that doesn't do nasty things with SS on privileged mode transitions. Regards, Anthony Liguori > Regards, > Guillaume > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel > |
|
From: Balaji R. <bal...@gm...> - 2008-05-05 12:44:35
|
On Monday 05 May 2008 06:10:08 pm Guillaume Thouvenin wrote: > On Sat, 3 May 2008 13:56:56 +0530 > > Balaji Rao <bal...@gm...> wrote: > > With your patch applied ubuntu 8.04 livecd fails to boot. Not any better > > with Marcelo's patch on top. > > Hi Balaji, > > And without the patch, can you boot the ubuntu 8.04 livecd? Yes, I can. :) > > Regards, > Guillaume -- Warm Regards, Balaji Rao Dept. of Mechanical Engineering NITK |
|
From: Guillaume T. <gui...@ex...> - 2008-05-05 12:41:24
|
On Sat, 3 May 2008 13:56:56 +0530 Balaji Rao <bal...@gm...> wrote: > With your patch applied ubuntu 8.04 livecd fails to boot. Not any better > with Marcelo's patch on top. Hi Balaji, And without the patch, can you boot the ubuntu 8.04 livecd? Regards, Guillaume |
|
From: Christian B. <bor...@de...> - 2008-05-05 12:30:39
|
> Hmm... this should help: > > --- > drivers/s390/kvm/kvm_virtio.c | 40 +++++++++++++++++++++++----------------- > 1 file changed, 23 insertions(+), 17 deletions(-) Thanks Heiko. I did a short test and it seems to work. Acked-by: Christian Borntraeger <bor...@de...> This looks almost identical to Rusty's patch. Who is going to send this (or Rustys) patch to Linus? Christian |
|
From: Michal L. <ml...@lo...> - 2008-05-05 12:14:11
|
Avi Kivity wrote: > Michal Ludvig wrote: >>>> >>>> loaded kvm module (kvm-68) >>>> kvm: emulating exchange as write >>>> Unable to handle kernel NULL pointer dereference at 0000000000000000 >>>> RIP: >>>> [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 >>> >>> Please apply the attached patch, and post 'dmesg | grep writeback'. >> >> writeback: b 01 mordm e0 >> > > Ah, it only affects pre-npt, so my testing was worthless. The attached > patch should fix. Ack. It runs fine now. Thanks. M. |
|
From: Avi K. <av...@qu...> - 2008-05-05 12:00:35
|
Michal Ludvig wrote: >>> >>> loaded kvm module (kvm-68) >>> kvm: emulating exchange as write >>> Unable to handle kernel NULL pointer dereference at 0000000000000000 >>> RIP: >>> [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 >> >> Please apply the attached patch, and post 'dmesg | grep writeback'. > > writeback: b 01 mordm e0 > Ah, it only affects pre-npt, so my testing was worthless. The attached patch should fix. -- error compiling committee.c: too many arguments to function |
|
From: Daniel P. B. <ber...@re...> - 2008-05-05 11:59:44
|
I'm forwarding this patch from upstream QEMU because its impotant to get this fixed in KVM to make serial console installs usable now libvirt can talk to KVM serial ports over PTYs. It was reported in this thread: http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00014.html With the final verson of the patch here: http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00135.html Recently committed to SVN http://svn.savannah.nongnu.org/viewvc?view=rev&root=qemu&revision=4338 [quote] If running a QEMU instance with a serial/parallel device connected to a Psuedo-TTY, eg '-serial pty', every \r\n sequence output by the guest is getting translated into a \n\n sequence by the TTY layer. So clients interacting with the serial port via a TTY done get the correct \r\n sequence and text marches to the right and wraps. This is because the TTY is not put into rawmode when QEMU sets it up. The following patch is a re-diff of a patch applied to Xen's QEMU code. It uses cfmakeraw() to ensure the TTY is put into rawmode, thus avoiding the incorrect \r\n translations. It also switches to tcsetattr() on the slave_fd instead of master_fd - although this is effectively the same on Linux, only slave_fd works on Solaris. Finally it stops using the 'name' arg to openpty() which is a security risk because its buffer size is undefined. Instead it makes use of the ptsname() function. [/quote] I'm attaching a patch re-diff for KVM. Technically the #iddef _sun__ bit is useless for KVM, but better to keep 100% in sync with QEMU code for easier future merges Signed-off-by: Daniel P. Berrange <ber...@re... Regards Daniel. diff --git a/qemu/vl.c b/qemu/vl.c index 74be059..b6b1c58 100644 --- a/qemu/vl.c +++ b/qemu/vl.c @@ -2301,28 +2301,78 @@ static CharDriverState *qemu_chr_open_stdio(void) return chr; } +#ifdef __sun__ +/* Once Solaris has openpty(), this is going to be removed. */ +int openpty(int *amaster, int *aslave, char *name, + struct termios *termp, struct winsize *winp) +{ + const char *slave; + int mfd = -1, sfd = -1; + + *amaster = *aslave = -1; + + mfd = open("/dev/ptmx", O_RDWR | O_NOCTTY); + if (mfd < 0) + goto err; + + if (grantpt(mfd) == -1 || unlockpt(mfd) == -1) + goto err; + + if ((slave = ptsname(mfd)) == NULL) + goto err; + + if ((sfd = open(slave, O_RDONLY | O_NOCTTY)) == -1) + goto err; + + if (ioctl(sfd, I_PUSH, "ptem") == -1 || + (termp != NULL && tcgetattr(sfd, termp) < 0)) + goto err; + + if (amaster) + *amaster = mfd; + if (aslave) + *aslave = sfd; + if (winp) + ioctl(sfd, TIOCSWINSZ, winp); + + return 0; + +err: + if (sfd != -1) + close(sfd); + close(mfd); + return -1; +} + +void cfmakeraw (struct termios *termios_p) +{ + termios_p->c_iflag &= + ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON); + termios_p->c_oflag &= ~OPOST; + termios_p->c_lflag &= ~(ECHO|ECHONL|ICANON|ISIG|IEXTEN); + termios_p->c_cflag &= ~(CSIZE|PARENB); + termios_p->c_cflag |= CS8; + + termios_p->c_cc[VMIN] = 0; + termios_p->c_cc[VTIME] = 0; +} +#endif + #if defined(__linux__) || defined(__sun__) static CharDriverState *qemu_chr_open_pty(void) { struct termios tty; - char slave_name[1024]; int master_fd, slave_fd; -#if defined(__linux__) - /* Not satisfying */ - if (openpty(&master_fd, &slave_fd, slave_name, NULL, NULL) < 0) { + if (openpty(&master_fd, &slave_fd, NULL, NULL, NULL) < 0) { return NULL; } -#endif - /* Disabling local echo and line-buffered output */ - tcgetattr (master_fd, &tty); - tty.c_lflag &= ~(ECHO|ICANON|ISIG); - tty.c_cc[VMIN] = 1; - tty.c_cc[VTIME] = 0; - tcsetattr (master_fd, TCSAFLUSH, &tty); + /* Set raw attributes on the pty. */ + cfmakeraw(&tty); + tcsetattr(slave_fd, TCSAFLUSH, &tty); - fprintf(stderr, "char device redirected to %s\n", slave_name); + fprintf(stderr, "char device redirected to %s\n", ptsname(master_fd)); return qemu_chr_open_fd(master_fd, master_fd); } -- |: Red Hat, Engineering, Boston -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 :| |
|
From: Michal L. <ml...@lo...> - 2008-05-05 11:10:06
|
Avi Kivity wrote: > Michal Ludvig wrote: >> >> Hi again, just wanted to let you know that I still get this Oops with >> kvm-68. It comes a bit later, not during the boot but after the XP >> desktop comes up. As there were some changes in kernel/x86_emulate.c >> the patch you provided for kvm-66 can't be applied anymore. >> >> loaded kvm module (kvm-68) >> kvm: emulating exchange as write >> Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: >> [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 > > Please apply the attached patch, and post 'dmesg | grep writeback'. writeback: b 01 mordm e0 M. |
|
From: Gerd H. <kr...@re...> - 2008-05-05 07:48:05
|
Marcelo Tosatti wrote: > On Thu, Apr 24, 2008 at 10:37:04AM +0200, Gerd Hoffmann wrote: >> Hi folks, >> >> My first attempt to send out a patch series with git ... >> >> The patches fix the kvm paravirt clocksource code to be compatible with >> xen and they also factor out some code which can be shared into a >> separate source files used by both kvm and xen. > > The issue with SMP guests is still present. Booting with "nohz=off" resolves it. > > Same symptoms as before, apic_timer_fn for one of the vcpu's is ticking way slower > than the remaining ones: > > [root@localhost ~]# cat /proc/timer_stats | grep apic > 391, 4125 qemu-system-x86 apic_mmio_write (apic_timer_fn) > 2103, 4126 qemu-system-x86 apic_mmio_write (apic_timer_fn) > 1896, 4127 qemu-system-x86 apic_mmio_write (apic_timer_fn) > 1857, 4128 qemu-system-x86 apic_mmio_write (apic_timer_fn) What userspace version is this? With iothread support? Or older one where the vcpu0 thread also handles all the I/O? Is 4x neeed to reproduce or do you see it with 2x too? What host? A quick test with xenner (which has a separate I/O thread) didn't show anything unusual. Going investigate ... cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/ |
|
From: Avi K. <av...@qu...> - 2008-05-05 07:23:22
|
Anthony Liguori wrote: > This patch reworks the IO thread to use signalfd() instead of sigtimedwait(). > This will eliminate the need to use SIGIO everywhere. In this version of the > patch, we use signalfd() when it's available. When it isn't available, we > create a separate thread and use sigwaitinfo() to simulate signalfd(). > > We cannot handle thread-specific signals with signalfd() emulation so also > replace SIGUSR1 notifications to the io-thread with an eventfd. Since eventfd > isn't always available, use pipe() to emulate eventfd. > Please break the SIGUSR1 changes into a separate patch. Ditto with *fd syscall compat. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-05 07:11:04
|
Michal Ludvig wrote: > > Hi again, just wanted to let you know that I still get this Oops with > kvm-68. It comes a bit later, not during the boot but after the XP > desktop comes up. As there were some changes in kernel/x86_emulate.c > the patch you provided for kvm-66 can't be applied anymore. > > loaded kvm module (kvm-68) > kvm: emulating exchange as write > Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: > [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 Please apply the attached patch, and post 'dmesg | grep writeback'. -- error compiling committee.c: too many arguments to function |
|
From: Izik E. <iz...@qu...> - 2008-05-05 07:04:52
|
Avi Kivity wrote: > Avi Kivity wrote: >> Izik Eidus wrote: >>> Michal Ludvig wrote: >>> >>>> Avi Kivity wrote: >>>> >>>>> Avi Kivity wrote: >>>>> >>>>>> Michal Ludvig wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I've experienced a kernel Oops on 2.6.24 with kvm 66 on AMD in >>>>>>> 64bit mode while starting up WinXP: >>>>>>> >>>>>>> The host is still alive but the XP guest is locked up in a boot >>>>>>> screen. >>>>>>> >>>> Hi again, just wanted to let you know that I still get this Oops >>>> with kvm-68. It comes a bit later, not during the boot but after the >>>> XP desktop comes up. As there were some changes in >>>> kernel/x86_emulate.c the patch you provided for kvm-66 can't be >>>> applied anymore. >>>> >>>> loaded kvm module (kvm-68) >>>> kvm: emulating exchange as write >>>> Unable to handle kernel NULL pointer dereference at 0000000000000000 >>>> RIP: >>>> [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 >>>> PGD 3145e067 PUD 409b9067 PMD 0 >>>> Oops: 0002 [1] SMP >>>> CPU 0 >>>> Modules linked in: kvm_amd kvm reiserfs tun bridge llc nfsd lockd >>>> nfs_acl auth_rpcgss sunrpc exportfs iptable_filter ip_tables autofs4 >>>> snd_pcm_oss snd_mixer_oss w83627ehf snd_seq snd_seq_device hwmon_vid >>>> ip6table_filter ip6_tables x_tables af_packet ipv6 fuse ext2 loop >>>> snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc sr_mod >>>> k8temp hwmon i2c_nforce2 button i2c_core cdrom forcedeth sg floppy >>>> linear ehci_hcd ohci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan >>>> sata_nv pata_amd libata scsi_mod thermal processor >>>> Pid: 14776, comm: qemu-system-x86 Not tainted 2.6.24-mludvig #1 >>>> RIP: 0010:[<ffffffff88373b4a>] [<ffffffff88373b4a>] >>>> :kvm:x86_emulate_insn+0x3fa/0x4240 >>>> RSP: 0018:ffff81007d52fc18 EFLAGS: 00010246 >>>> RAX: 000000008001003b RBX: 0000000000000000 RCX: 0000000000000000 >>>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff810079c5c000 >>>> RBP: ffff810079c5d320 R08: ffff810079c5d3c0 R09: 0000000000000006 >>>> R10: 0000000000000002 R11: 0000000000000000 R12: ffff810079c5d368 >>>> R13: ffff810079c5d3c0 R14: ffffffff8838ab20 R15: 00000000019d1353 >>>> FS: 0000000040800950(0063) GS:ffffffff8053e000(0000) >>>> knlGS:0000000000000000 >>>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >>>> CR2: 0000000000000000 CR3: 000000007985a000 CR4: 00000000000006e0 >>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >>>> Process qemu-system-x86 (pid: 14776, threadinfo ffff81007d52e000, >>>> task ffff81003f4e6780) >>>> Stack: 000000007d52fc74 0000000011fda618 000000000f399068 >>>> ffff810079c5d3c0 >>>> ffff81007d52fc94 ffffffff88368ae0 0000000000000000 ffff810079c5c000 >>>> ffff810079c5d320 0000000000000000 0000000000000000 0000000000000000 >>>> Call Trace: >>>> [<ffffffff88368ae0>] :kvm:seg_desct_to_kvm_desct+0x40/0xb0 >>>> >>> >>> ok, if we are here it mean windows did task switch, >>> and if windows did task switch it mean something was probably wrong >>> before. >>> >>> >> >> We need to fix the oops regardless. >> >> > > Oh, I think that's just garbage on the stack. Actual oops is in > x86_emulate_insn. > i saw that the opss was in x86_emulate_insn, you think that seg_desct_to_kvm_desct never got called? (i would expect to see more traces before this function such as task_switch()... -- woof. |
|
From: Avi K. <av...@qu...> - 2008-05-05 07:02:53
|
Avi Kivity wrote: > Izik Eidus wrote: >> Michal Ludvig wrote: >> >>> Avi Kivity wrote: >>> >>>> Avi Kivity wrote: >>>> >>>>> Michal Ludvig wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've experienced a kernel Oops on 2.6.24 with kvm 66 on AMD in >>>>>> 64bit mode while starting up WinXP: >>>>>> >>>>>> The host is still alive but the XP guest is locked up in a boot >>>>>> screen. >>>>>> >>> Hi again, just wanted to let you know that I still get this Oops >>> with kvm-68. It comes a bit later, not during the boot but after the >>> XP desktop comes up. As there were some changes in >>> kernel/x86_emulate.c the patch you provided for kvm-66 can't be >>> applied anymore. >>> >>> loaded kvm module (kvm-68) >>> kvm: emulating exchange as write >>> Unable to handle kernel NULL pointer dereference at 0000000000000000 >>> RIP: >>> [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 >>> PGD 3145e067 PUD 409b9067 PMD 0 >>> Oops: 0002 [1] SMP >>> CPU 0 >>> Modules linked in: kvm_amd kvm reiserfs tun bridge llc nfsd lockd >>> nfs_acl auth_rpcgss sunrpc exportfs iptable_filter ip_tables autofs4 >>> snd_pcm_oss snd_mixer_oss w83627ehf snd_seq snd_seq_device hwmon_vid >>> ip6table_filter ip6_tables x_tables af_packet ipv6 fuse ext2 loop >>> snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc sr_mod >>> k8temp hwmon i2c_nforce2 button i2c_core cdrom forcedeth sg floppy >>> linear ehci_hcd ohci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan >>> sata_nv pata_amd libata scsi_mod thermal processor >>> Pid: 14776, comm: qemu-system-x86 Not tainted 2.6.24-mludvig #1 >>> RIP: 0010:[<ffffffff88373b4a>] [<ffffffff88373b4a>] >>> :kvm:x86_emulate_insn+0x3fa/0x4240 >>> RSP: 0018:ffff81007d52fc18 EFLAGS: 00010246 >>> RAX: 000000008001003b RBX: 0000000000000000 RCX: 0000000000000000 >>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff810079c5c000 >>> RBP: ffff810079c5d320 R08: ffff810079c5d3c0 R09: 0000000000000006 >>> R10: 0000000000000002 R11: 0000000000000000 R12: ffff810079c5d368 >>> R13: ffff810079c5d3c0 R14: ffffffff8838ab20 R15: 00000000019d1353 >>> FS: 0000000040800950(0063) GS:ffffffff8053e000(0000) >>> knlGS:0000000000000000 >>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >>> CR2: 0000000000000000 CR3: 000000007985a000 CR4: 00000000000006e0 >>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >>> Process qemu-system-x86 (pid: 14776, threadinfo ffff81007d52e000, >>> task ffff81003f4e6780) >>> Stack: 000000007d52fc74 0000000011fda618 000000000f399068 >>> ffff810079c5d3c0 >>> ffff81007d52fc94 ffffffff88368ae0 0000000000000000 ffff810079c5c000 >>> ffff810079c5d320 0000000000000000 0000000000000000 0000000000000000 >>> Call Trace: >>> [<ffffffff88368ae0>] :kvm:seg_desct_to_kvm_desct+0x40/0xb0 >>> >> >> ok, if we are here it mean windows did task switch, >> and if windows did task switch it mean something was probably wrong >> before. >> >> > > We need to fix the oops regardless. > > Oh, I think that's just garbage on the stack. Actual oops is in x86_emulate_insn. -- error compiling committee.c: too many arguments to function |
|
From: Izik E. <iz...@qu...> - 2008-05-05 07:01:58
|
Avi Kivity wrote: > Izik Eidus wrote: >> Michal Ludvig wrote: >> >>> Avi Kivity wrote: >>> >>>> Avi Kivity wrote: >>>> >>>>> Michal Ludvig wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've experienced a kernel Oops on 2.6.24 with kvm 66 on AMD in >>>>>> 64bit mode while starting up WinXP: >>>>>> >>>>>> The host is still alive but the XP guest is locked up in a boot >>>>>> screen. >>>>>> >>> Hi again, just wanted to let you know that I still get this Oops with >>> kvm-68. It comes a bit later, not during the boot but after the XP >>> desktop comes up. As there were some changes in kernel/x86_emulate.c >>> the patch you provided for kvm-66 can't be applied anymore. >>> >>> loaded kvm module (kvm-68) >>> kvm: emulating exchange as write >>> Unable to handle kernel NULL pointer dereference at 0000000000000000 >>> RIP: >>> [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 >>> PGD 3145e067 PUD 409b9067 PMD 0 >>> Oops: 0002 [1] SMP >>> CPU 0 >>> Modules linked in: kvm_amd kvm reiserfs tun bridge llc nfsd lockd >>> nfs_acl auth_rpcgss sunrpc exportfs iptable_filter ip_tables autofs4 >>> snd_pcm_oss snd_mixer_oss w83627ehf snd_seq snd_seq_device hwmon_vid >>> ip6table_filter ip6_tables x_tables af_packet ipv6 fuse ext2 loop >>> snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc sr_mod >>> k8temp hwmon i2c_nforce2 button i2c_core cdrom forcedeth sg floppy >>> linear ehci_hcd ohci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan >>> sata_nv pata_amd libata scsi_mod thermal processor >>> Pid: 14776, comm: qemu-system-x86 Not tainted 2.6.24-mludvig #1 >>> RIP: 0010:[<ffffffff88373b4a>] [<ffffffff88373b4a>] >>> :kvm:x86_emulate_insn+0x3fa/0x4240 >>> RSP: 0018:ffff81007d52fc18 EFLAGS: 00010246 >>> RAX: 000000008001003b RBX: 0000000000000000 RCX: 0000000000000000 >>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff810079c5c000 >>> RBP: ffff810079c5d320 R08: ffff810079c5d3c0 R09: 0000000000000006 >>> R10: 0000000000000002 R11: 0000000000000000 R12: ffff810079c5d368 >>> R13: ffff810079c5d3c0 R14: ffffffff8838ab20 R15: 00000000019d1353 >>> FS: 0000000040800950(0063) GS:ffffffff8053e000(0000) >>> knlGS:0000000000000000 >>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >>> CR2: 0000000000000000 CR3: 000000007985a000 CR4: 00000000000006e0 >>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >>> Process qemu-system-x86 (pid: 14776, threadinfo ffff81007d52e000, >>> task ffff81003f4e6780) >>> Stack: 000000007d52fc74 0000000011fda618 000000000f399068 >>> ffff810079c5d3c0 >>> ffff81007d52fc94 ffffffff88368ae0 0000000000000000 ffff810079c5c000 >>> ffff810079c5d320 0000000000000000 0000000000000000 0000000000000000 >>> Call Trace: >>> [<ffffffff88368ae0>] :kvm:seg_desct_to_kvm_desct+0x40/0xb0 >>> >> >> ok, if we are here it mean windows did task switch, >> and if windows did task switch it mean something was probably wrong >> before. >> >> > > We need to fix the oops regardless. > > i know..., it was just an hint... -- woof. |
|
From: Avi K. <av...@qu...> - 2008-05-05 06:59:50
|
Izik Eidus wrote: > Michal Ludvig wrote: > >> Avi Kivity wrote: >> >>> Avi Kivity wrote: >>> >>>> Michal Ludvig wrote: >>>> >>>>> Hi, >>>>> >>>>> I've experienced a kernel Oops on 2.6.24 with kvm 66 on AMD in 64bit >>>>> mode while starting up WinXP: >>>>> >>>>> The host is still alive but the XP guest is locked up in a boot screen. >>>>> >> Hi again, just wanted to let you know that I still get this Oops with >> kvm-68. It comes a bit later, not during the boot but after the XP >> desktop comes up. As there were some changes in kernel/x86_emulate.c the >> patch you provided for kvm-66 can't be applied anymore. >> >> loaded kvm module (kvm-68) >> kvm: emulating exchange as write >> Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: >> [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 >> PGD 3145e067 PUD 409b9067 PMD 0 >> Oops: 0002 [1] SMP >> CPU 0 >> Modules linked in: kvm_amd kvm reiserfs tun bridge llc nfsd lockd >> nfs_acl auth_rpcgss sunrpc exportfs iptable_filter ip_tables autofs4 >> snd_pcm_oss snd_mixer_oss w83627ehf snd_seq snd_seq_device hwmon_vid >> ip6table_filter ip6_tables x_tables af_packet ipv6 fuse ext2 loop >> snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc sr_mod >> k8temp hwmon i2c_nforce2 button i2c_core cdrom forcedeth sg floppy >> linear ehci_hcd ohci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan >> sata_nv pata_amd libata scsi_mod thermal processor >> Pid: 14776, comm: qemu-system-x86 Not tainted 2.6.24-mludvig #1 >> RIP: 0010:[<ffffffff88373b4a>] [<ffffffff88373b4a>] >> :kvm:x86_emulate_insn+0x3fa/0x4240 >> RSP: 0018:ffff81007d52fc18 EFLAGS: 00010246 >> RAX: 000000008001003b RBX: 0000000000000000 RCX: 0000000000000000 >> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff810079c5c000 >> RBP: ffff810079c5d320 R08: ffff810079c5d3c0 R09: 0000000000000006 >> R10: 0000000000000002 R11: 0000000000000000 R12: ffff810079c5d368 >> R13: ffff810079c5d3c0 R14: ffffffff8838ab20 R15: 00000000019d1353 >> FS: 0000000040800950(0063) GS:ffffffff8053e000(0000) knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >> CR2: 0000000000000000 CR3: 000000007985a000 CR4: 00000000000006e0 >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >> Process qemu-system-x86 (pid: 14776, threadinfo ffff81007d52e000, task >> ffff81003f4e6780) >> Stack: 000000007d52fc74 0000000011fda618 000000000f399068 ffff810079c5d3c0 >> ffff81007d52fc94 ffffffff88368ae0 0000000000000000 ffff810079c5c000 >> ffff810079c5d320 0000000000000000 0000000000000000 0000000000000000 >> Call Trace: >> [<ffffffff88368ae0>] :kvm:seg_desct_to_kvm_desct+0x40/0xb0 >> > > ok, if we are here it mean windows did task switch, > and if windows did task switch it mean something was probably wrong before. > > We need to fix the oops regardless. -- error compiling committee.c: too many arguments to function |
|
From: Izik E. <iz...@qu...> - 2008-05-05 06:46:18
|
Michal Ludvig wrote: > Avi Kivity wrote: >> Avi Kivity wrote: >>> Michal Ludvig wrote: >>>> Hi, >>>> >>>> I've experienced a kernel Oops on 2.6.24 with kvm 66 on AMD in 64bit >>>> mode while starting up WinXP: >>>> >>>> The host is still alive but the XP guest is locked up in a boot screen. > > Hi again, just wanted to let you know that I still get this Oops with > kvm-68. It comes a bit later, not during the boot but after the XP > desktop comes up. As there were some changes in kernel/x86_emulate.c the > patch you provided for kvm-66 can't be applied anymore. > > loaded kvm module (kvm-68) > kvm: emulating exchange as write > Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: > [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 > PGD 3145e067 PUD 409b9067 PMD 0 > Oops: 0002 [1] SMP > CPU 0 > Modules linked in: kvm_amd kvm reiserfs tun bridge llc nfsd lockd > nfs_acl auth_rpcgss sunrpc exportfs iptable_filter ip_tables autofs4 > snd_pcm_oss snd_mixer_oss w83627ehf snd_seq snd_seq_device hwmon_vid > ip6table_filter ip6_tables x_tables af_packet ipv6 fuse ext2 loop > snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc sr_mod > k8temp hwmon i2c_nforce2 button i2c_core cdrom forcedeth sg floppy > linear ehci_hcd ohci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan > sata_nv pata_amd libata scsi_mod thermal processor > Pid: 14776, comm: qemu-system-x86 Not tainted 2.6.24-mludvig #1 > RIP: 0010:[<ffffffff88373b4a>] [<ffffffff88373b4a>] > :kvm:x86_emulate_insn+0x3fa/0x4240 > RSP: 0018:ffff81007d52fc18 EFLAGS: 00010246 > RAX: 000000008001003b RBX: 0000000000000000 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff810079c5c000 > RBP: ffff810079c5d320 R08: ffff810079c5d3c0 R09: 0000000000000006 > R10: 0000000000000002 R11: 0000000000000000 R12: ffff810079c5d368 > R13: ffff810079c5d3c0 R14: ffffffff8838ab20 R15: 00000000019d1353 > FS: 0000000040800950(0063) GS:ffffffff8053e000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000000000000 CR3: 000000007985a000 CR4: 00000000000006e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process qemu-system-x86 (pid: 14776, threadinfo ffff81007d52e000, task > ffff81003f4e6780) > Stack: 000000007d52fc74 0000000011fda618 000000000f399068 ffff810079c5d3c0 > ffff81007d52fc94 ffffffff88368ae0 0000000000000000 ffff810079c5c000 > ffff810079c5d320 0000000000000000 0000000000000000 0000000000000000 > Call Trace: > [<ffffffff88368ae0>] :kvm:seg_desct_to_kvm_desct+0x40/0xb0 ok, if we are here it mean windows did task switch, and if windows did task switch it mean something was probably wrong before. > [<ffffffff88369dff>] :kvm:emulate_instruction+0x1bf/0x340 > [<ffffffff883d99e2>] :kvm_amd:emulate_on_interception+0x12/0x60 > [<ffffffff8836d2b9>] :kvm:kvm_arch_vcpu_ioctl_run+0x169/0x6d0 > [<ffffffff883681fc>] :kvm:kvm_vcpu_ioctl+0x41c/0x440 > [<ffffffff802305f3>] __wake_up+0x43/0x70 > [<ffffffff803374c1>] __up_read+0x21/0xb0 > [<ffffffff802586ec>] futex_wake+0xcc/0xf0 > [<ffffffff80259559>] do_futex+0x129/0xbb0 > [<ffffffff8022e7bd>] __dequeue_entity+0x3d/0x50 > [<ffffffff883679c5>] :kvm:kvm_vm_ioctl+0x85/0x200 > [<ffffffff8044357f>] thread_return+0x3a/0x62b > [<ffffffff8027a620>] do_writepages+0x20/0x40 > [<ffffffff802ab10f>] do_ioctl+0x2f/0xa0 > [<ffffffff802ab3a0>] vfs_ioctl+0x220/0x2d0 > [<ffffffff802ab4e1>] sys_ioctl+0x91/0xb0 > [<ffffffff8020bcae>] system_call+0x7e/0x83 > > > Code: 66 89 02 e9 ee fc ff ff 48 8b 95 88 00 00 00 48 8b 45 78 88 > RIP [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 > RSP <ffff81007d52fc18> > CR2: 0000000000000000 > ---[ end trace d485159bd8f95a33 ]--- > > Michal > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel -- woof. |
|
From: Guillaume T. <gui...@ex...> - 2008-05-05 06:30:56
|
On Thu, 1 May 2008 16:13:31 -0300
Marcelo Tosatti <mto...@re...> wrote:
> The code sequence is:
>
> 8235: 66 data16
> 8236: 0f 22 c0 mov %eax,%cr0
> 8239: ea 3e 02 00 08 b8 00 ljmp $0xb8,$0x800023e
>
> So it switches to realmode and then does a ljmp. Problem is that you're
> using the segment selector as a GDT index, but in realmode it should be
> shifted left by 4 to determine the segment base address. Following patch
> makes Plan9 happy.
>
> Other than that, load_segment_descriptor() can return a positive error
> on failure, should do a proper check.
>
> Index: kvm/arch/x86/kvm/x86_emulate.c
> ===================================================================
> --- kvm.orig/arch/x86/kvm/x86_emulate.c
> +++ kvm/arch/x86/kvm/x86_emulate.c
> @@ -1755,7 +1755,10 @@ special_insn:
> goto cannot_emulate;
> }
> sel = insn_fetch(u16, 2, c->eip);
> - if (load_segment_descriptor(ctxt->vcpu, sel, 9, VCPU_SREG_CS) < 0) {
> + if (ctxt->mode == X86EMUL_MODE_REAL)
> + eip |= (sel << 4);
> + else if (load_segment_descriptor(ctxt->vcpu, sel, 9,
> + VCPU_SREG_CS) < 0) {
> DPRINTF("jmp far: Failed to load CS descriptor\n");
> goto cannot_emulate;
> }
>
Thank you Marcelo for the report. Unfortunately it is not the same
problem I'm seeing. The problem I have now is that I can boot until the
gfxboot screen but when I choose to install openSuse it generates a
kernel panic like this:
[guill@enterprise][~/local/kvm-userspace.git/bin]$ ./qemu-system-x86_64
-hda ~/disk_images/hd_50G.qcow2 -cdrom /images_iso/openSUSE-10.3-GM-x86_64-mini.iso -boot d -s -m 1024 -serial stdio
Linux version 2.6.22.5-31-default (geeko@buildhost) (gcc version 4.2.1 (SUSE Linux)) #1 SMP 2007/09/21 22:29:00 UTC
Command line: BOOT_IMAGE=linux initrd=initrd,08000600.spl splash=silent vga=0x314 install=slp:/ console=ttyS0
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
BIOS-e820: 000000003fff0000 - 0000000040000000 (ACPI data)
BIOS-e820: 00000000fffbd000 - 0000000100000000 (reserved)
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000FB450, 0014 (r0 QEMU )
ACPI: RSDT 3FFF0000, 002C (r1 QEMU QEMURSDT 1 QEMU 1)
ACPI: FACP 3FFF002C, 0074 (r1 QEMU QEMUFACP 1 QEMU 1)
ACPI: DSDT 3FFF0100, 2464 (r1 BXPC BXDSDT 1 INTL 20061109)
ACPI: FACS 3FFF00C0, 0040
ACPI: APIC 3FFF2568, 00E0 (r1 QEMU QEMUAPIC 1 QEMU 1)
No NUMA configuration found
Faking a node at 0000000000000000-000000003fff0000
Bootmem setup node 0 0000000000000000-000000003fff0000
No mptable found.
Zone PFN ranges:
DMA 0 -> 4096
DMA32 4096 -> 1048576
Normal 1048576 -> 1048576
early_node_map[2] active PFN ranges
0: 0 -> 159
0: 256 -> 262128
ACPI: PM-Timer IO Port: 0xb008
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] disabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] disabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] disabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] disabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] disabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] disabled)
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0c] disabled)
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0d] disabled)
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0e] disabled)
ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0f] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 000000000009f000 - 00000000000a0000
swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000e8000
swsusp: Registered nosave memory region: 00000000000e8000 - 0000000000100000
Allocating PCI resources starting at 50000000 (gap: 40000000:bffbd000)
SMP: Allowing 16 CPUs, 15 hotplug CPUs
PERCPU: Allocating 50296 bytes of per cpu data
Built 1 zonelists. Total pages: 257180
Kernel command line: BOOT_IMAGE=linux initrd=initrd,08000600.spl splash=silent vga=0x314 install=slp:/ console=ttyS0
bootsplash: silent mode.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Detected 3002.939 MHz processor.
Console: colour dummy device 80x25
Checking aperture...
Memory: 1012688k/1048512k available (2050k kernel code, 35436k reserved, 1017k data, 316k init)
Calibrating delay using timer specific routine.. 6034.80 BogoMIPS (lpj=12069613)
Security Framework v1.0.0 initialized
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU 0/0 -> Node 0
invalid opcode: 0000 [1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.22.5-31-default #1
RIP: 0010:[<ffffffff80283be4>] [<ffffffff80283be4>] kmem_cache_zalloc+0x8d/0xad
RSP: 0018:ffffffff805c7f18 EFLAGS: 00010046
RAX: 000000000000000a RBX: 0000000000000046 RCX: 0000000000000000
RDX: ffff8100015dfa40 RSI: 0000000000000001 RDI: ffff81003ffd33d8
RBP: 00000000000000d0 R08: 0000000000000000 R09: ffffffff804b6870
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8100015d2080
R13: ffffffff805cf298 R14: ffffffff805c9000 R15: ffffffff804673bd
FS: 0000000000000000(0000) GS:ffffffff804ff000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
Process swapper (pid: 0, threadinfo ffffffff805c6000, task ffffffff804b6870)
Stack: 0000000000000282 ffffffff804009a5 ffffffff80200000 ffffffff80210e10
0000000000000000 ffffffff802f3841 0000000000000000 0000000000000282
0000000000000000 0000000000000000 ffffffffffffffff ffffffff805f2700
Call Trace:
[<ffffffff804009a5>] _etext+0x0/0x1cf65b
[<ffffffff80210e10>] alternatives_smp_module_add+0x77/0x149
[<ffffffff802f3841>] __bitmap_weight+0x39/0x80
[<ffffffff805d607e>] alternative_instructions+0xdf/0xea
[<ffffffff805d076c>] start_kernel+0x2c0/0x2db
[<ffffffff805d0148>] _sinittext+0x148/0x14c
Code: 0f 0d 0a 48 85 d2 74 10 41 8b 8c 24 0c 04 00 00 31 c0 48 89
RIP [<ffffffff80283be4>] kmem_cache_zalloc+0x8d/0xad
RSP <ffffffff805c7f18>
Kernel panic - not syncing: Attempted to kill the idle task!
....................
Anyway your remark about the usage of the segment selector in real mode
or not is true and I added your patch in my series of patches. I will
also make proper check with return value of load_segment_descriptor().
Best regards,
Guillaume
|
|
From: SourceForge.net <no...@so...> - 2008-05-05 05:57:33
|
Bugs item #1935481, was opened at 2008-04-05 09:37 Message generated for change (Comment added) made by jakeogh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1935481&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: None Priority: 5 Private: No Submitted By: Balaji Rao R (balajirrao) Assigned to: Nobody/Anonymous (nobody) Summary: unhandled vm exit: 0x80000021 vcpu_id 0 Initial Comment: Win Vista Ultimate 32 bit does not work. It works fine with -no-kvm. No problems during installation. Problem surfaces only on first boot. bash-3.2# qemu-system-x86_64 -m 1536 -hda vista.img unhandled vm exit: 0x80000021 vcpu_id 0 rax 0000000000000010 rbx 0000000000000080 rcx 0000000000000000 rdx 0000000000000080 rsi 000000000026b238 rdi 000000000008b238 rsp 0000000000000200 rbp 0000000000001f20 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 000000000000009b rflags 00023002 cs b000 (002b0000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 0020 (00000200/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 0020 (00000200/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 0020 (00000200/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 0020 (00000200/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs 0020 (00000200/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr 0000 (fffbd000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 2b0000/27 idt 0/3ff cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 Aborted ---------------------------------------------------------------------- Comment By: Justin Keogh (jakeogh) Date: 2008-05-04 22:57 Message: Logged In: YES user_id=2079304 Originator: NO I got the same error with kvm-67 on: Linux xeonbox 2.6.25-gentoo-r1 #14 SMP Mon May 5 03:46:09 MST 2008 x86_64 Intel(R) Xeon(R) CPU X5482 @ 3.20GHz GenuineIntel GNU/Linux guest: windows vista ultimate 32bit... crash happens on first boot after install. -no-acapi didnt help. -no-kvm works. ---------------------------------------------------------------------- Comment By: Balaji Rao R (balajirrao) Date: 2008-04-06 07:22 Message: Logged In: YES user_id=1958935 Originator: YES Thats weird. Let me try, I'm working to fix it, or atleast to understand the problem better. ---------------------------------------------------------------------- Comment By: Technologov (technologov) Date: 2008-04-06 07:04 Message: Logged In: YES user_id=1839746 Originator: NO Unreproducible. -Alexey "Technologov". ---------------------------------------------------------------------- Comment By: Balaji Rao R (balajirrao) Date: 2008-04-06 06:58 Message: Logged In: YES user_id=1958935 Originator: YES I'm not sure if its a regression. The first time ever I installed and tried booting vista, it wouldn't run. ---------------------------------------------------------------------- Comment By: Avi Kivity (avik) Date: 2008-04-06 06:34 Message: Logged In: YES user_id=539971 Originator: NO Is this a regression? If so, which kvm version worked last? I've successfully installed and booted Vista in the past. ---------------------------------------------------------------------- Comment By: Balaji Rao R (balajirrao) Date: 2008-04-05 12:26 Message: Logged In: YES user_id=1958935 Originator: YES Some critical facts i missed.. Host : Intel I forgot to mention the version too! KVM : kvm-64-210-g78e0016 kvm-userspace : kvm-64-18-gd84f71a ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1935481&group_id=180599 |
|
From: Zhang, X. <xia...@in...> - 2008-05-05 05:12:08
|
Hi, Avi This patch should go into RC1, otherwise it will block kvm/ia64 userspace build. Xiantao >From 55584a9ecdfbea61ab90014c9cc14c5a22b696dd Mon Sep 17 00:00:00 2001 From: Xiantao Zhang <xia...@in...> Date: Mon, 5 May 2008 12:49:35 +0800 Subject: [PATCH] KVM: KVM/ia64: built fix for kvm userspace. kvm.h is shared by userspace and kernel, and it needs to include different headers in two cases. Signed-off-by: Xiantao Zhang <xia...@in...> --- include/asm-ia64/kvm.h | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/asm-ia64/kvm.h b/include/asm-ia64/kvm.h index eb2d355..62b5fad 100644 --- a/include/asm-ia64/kvm.h +++ b/include/asm-ia64/kvm.h @@ -22,7 +22,12 @@ */ #include <asm/types.h> + +#ifdef __KERNEL__ #include <asm/fpu.h> +#else +#include <signal.h> +#endif #include <linux/ioctl.h> -- 1.5.2 |
|
From: 李 <li...@12...> - 2008-05-05 02:34:08
|
广州嘉集财税代理有限公司
联系人：林小姐 传真/Fax: 020-33789285
联系电话/Tel: 13631387231
致:，财务/经理
广州嘉集财税代理有限公司。与全国各地区众多公司有业务往来，可长期代理全国各地（国税/地税）
等业务，{商品销售 工程建筑 广告 咨询 租赁 服务 餐饮 运输}等税-票向外代开。若贵公司/厂家在
做帐或其他方面有需要，可来电咨询洽谈。本公司郑重承诺：所开出税-票均为税务局所申领，可供网上
查询或税务局验证后付款。
真诚希望与厂大公司(厂家)携手合作,共同谋求发展,不明请来电咨询。您的满意就是我们服务的宗旨!
联系人: 林小姐 传真/Fax: 020-33789285
联系电话/Tel:13631387231
顺祝商祺
（如有打扰之处敬请谅解）
{广东省（东莞/深圳/佛山/中山。。。）广西/福建/上海/江苏/北京/山东/浙江/辽宁等}都有分公司
|
|
From: Robin H. <ho...@sg...> - 2008-05-05 02:25:47
|
On Mon, May 05, 2008 at 12:08:25AM +0200, Andrea Arcangeli wrote: > On Sun, May 04, 2008 at 02:13:45PM -0500, Robin Holt wrote: > > > diff --git a/mm/Kconfig b/mm/Kconfig > > > --- a/mm/Kconfig > > > +++ b/mm/Kconfig > > > @@ -205,3 +205,6 @@ config VIRT_TO_BUS > > > config VIRT_TO_BUS > > > def_bool y > > > depends on !ARCH_NO_VIRT_TO_BUS > > > + > > > +config MMU_NOTIFIER > > > + bool > > > > Without some text following the bool keyword, I am not even asked for > > this config setting on my ia64 build. > > Yes, this was explicitly asked by Andrew after his review. This is the > explanation pasted from the changelog. > > 3) It'd be a waste to add branches in the VM if nobody could possibly > run KVM/GRU/XPMEM on the kernel, so mmu notifiers will only enabled > if CONFIG_KVM=m/y. In the current kernel kvm won't yet take > advantage of mmu notifiers, but this already allows to compile a > KVM external module against a kernel with mmu notifiers enabled and > from the next pull from kvm.git we'll start using them. And > GRU/XPMEM will also be able to continue the development by enabling > KVM=m in their config, until they submit all GRU/XPMEM GPLv2 code > to the mainline kernel. Then they can also enable MMU_NOTIFIERS in > the same way KVM does it (even if KVM=n). This guarantees nobody > selects MMU_NOTIFIER=y if KVM and GRU and XPMEM are all =n. Ah, so Andrew wants users of KVM to do a select of MMU_NOTIFIER. That makes sense. I will change (fix) my Kconfig changes. Thanks, Robin |
|
From: Rusty R. <ru...@ru...> - 2008-05-05 00:19:04
|
On Sunday 04 May 2008 03:47:17 Adrian Bunk wrote:
> Commit c45a6816c19dee67b8f725e6646d428901a6dc24
> (virtio: explicit advertisement of driver features)
> and commit e976a2b997fc4ad70ccc53acfe62811c4aaec851
> (s390: KVM guest: virtio device support, and kvm hypercalls)
> don't like each other:
Yep, I broke s390. This was kind of expected, but I didn't want to try to
fix it as I am unable to test.
It would look something like this:
virtio: Attempt to fix kvm_virtio after feature management changes
Very similar to lguest code: set and get feature are now separate callbacks.
Signed-off-by: Rusty Russell <ru...@ru...>
diff -r 219d6c116996 drivers/s390/kvm/kvm_virtio.c
--- a/drivers/s390/kvm/kvm_virtio.c Mon May 05 10:03:16 2008 +1000
+++ b/drivers/s390/kvm/kvm_virtio.c Mon May 05 10:17:25 2008 +1000
@@ -78,27 +78,34 @@ static unsigned desc_size(const struct k
+ desc->config_len;
}
-/*
- * This tests (and acknowleges) a feature bit.
- */
-static bool kvm_feature(struct virtio_device *vdev, unsigned fbit)
+/* This gets the device's feature bits. */
+static u32 kvm_get_features(struct virtio_device *vdev)
{
+ unsigned int i;
+ u32 features = 0;
struct kvm_device_desc *desc = to_kvmdev(vdev)->desc;
- u8 *features;
+ u8 *in_features = kvm_vq_features(desc);
- if (fbit / 8 > desc->feature_len)
- return false;
+ /* We do this the slow but generic way. */
+ for (i = 0; i < min(desc->feature_len * 8, 32); i++)
+ if (in_features[i / 8] & (1 << (i % 8)))
+ features |= (1 << i);
- features = kvm_vq_features(desc);
- if (!(features[fbit / 8] & (1 << (fbit % 8))))
- return false;
+ return features;
+}
- /*
- * We set the matching bit in the other half of the bitmap to tell the
- * Host we want to use this feature.
- */
- features[desc->feature_len + fbit / 8] |= (1 << (fbit % 8));
- return true;
+static void kvm_set_features(struct virtio_device *vdev, u32 features)
+{
+ unsigned int i;
+ struct kvm_device_desc *desc = to_kvmdev(vdev)->desc;
+ /* Second half of bitmap is features we accept. */
+ u8 *out_features = kvm_vq_features(desc) + desc->feature_len;
+
+ memset(out_features, 0, desc->feature_len);
+ for (i = 0; i < min(desc->feature_len * 8, 32); i++) {
+ if (features & (1 << i))
+ out_features[i / 8] |= (1 << (i % 8));
+ }
}
/*
@@ -221,7 +228,8 @@ static void kvm_del_vq(struct virtqueue
* The config ops structure as defined by virtio config
*/
static struct virtio_config_ops kvm_vq_configspace_ops = {
- .feature = kvm_feature,
+ .get_features = kvm_get_features,
+ .set_features = kvm_set_features,
.get = kvm_get,
.set = kvm_set,
.get_status = kvm_get_status,
|
|
From: Michal L. <ml...@lo...> - 2008-05-04 23:01:36
|
Avi Kivity wrote: > Avi Kivity wrote: >> Michal Ludvig wrote: >>> Hi, >>> >>> I've experienced a kernel Oops on 2.6.24 with kvm 66 on AMD in 64bit >>> mode while starting up WinXP: >>> >>> The host is still alive but the XP guest is locked up in a boot screen. Hi again, just wanted to let you know that I still get this Oops with kvm-68. It comes a bit later, not during the boot but after the XP desktop comes up. As there were some changes in kernel/x86_emulate.c the patch you provided for kvm-66 can't be applied anymore. loaded kvm module (kvm-68) kvm: emulating exchange as write Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 PGD 3145e067 PUD 409b9067 PMD 0 Oops: 0002 [1] SMP CPU 0 Modules linked in: kvm_amd kvm reiserfs tun bridge llc nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs iptable_filter ip_tables autofs4 snd_pcm_oss snd_mixer_oss w83627ehf snd_seq snd_seq_device hwmon_vid ip6table_filter ip6_tables x_tables af_packet ipv6 fuse ext2 loop snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc sr_mod k8temp hwmon i2c_nforce2 button i2c_core cdrom forcedeth sg floppy linear ehci_hcd ohci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan sata_nv pata_amd libata scsi_mod thermal processor Pid: 14776, comm: qemu-system-x86 Not tainted 2.6.24-mludvig #1 RIP: 0010:[<ffffffff88373b4a>] [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 RSP: 0018:ffff81007d52fc18 EFLAGS: 00010246 RAX: 000000008001003b RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff810079c5c000 RBP: ffff810079c5d320 R08: ffff810079c5d3c0 R09: 0000000000000006 R10: 0000000000000002 R11: 0000000000000000 R12: ffff810079c5d368 R13: ffff810079c5d3c0 R14: ffffffff8838ab20 R15: 00000000019d1353 FS: 0000000040800950(0063) GS:ffffffff8053e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000007985a000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process qemu-system-x86 (pid: 14776, threadinfo ffff81007d52e000, task ffff81003f4e6780) Stack: 000000007d52fc74 0000000011fda618 000000000f399068 ffff810079c5d3c0 ffff81007d52fc94 ffffffff88368ae0 0000000000000000 ffff810079c5c000 ffff810079c5d320 0000000000000000 0000000000000000 0000000000000000 Call Trace: [<ffffffff88368ae0>] :kvm:seg_desct_to_kvm_desct+0x40/0xb0 [<ffffffff88369dff>] :kvm:emulate_instruction+0x1bf/0x340 [<ffffffff883d99e2>] :kvm_amd:emulate_on_interception+0x12/0x60 [<ffffffff8836d2b9>] :kvm:kvm_arch_vcpu_ioctl_run+0x169/0x6d0 [<ffffffff883681fc>] :kvm:kvm_vcpu_ioctl+0x41c/0x440 [<ffffffff802305f3>] __wake_up+0x43/0x70 [<ffffffff803374c1>] __up_read+0x21/0xb0 [<ffffffff802586ec>] futex_wake+0xcc/0xf0 [<ffffffff80259559>] do_futex+0x129/0xbb0 [<ffffffff8022e7bd>] __dequeue_entity+0x3d/0x50 [<ffffffff883679c5>] :kvm:kvm_vm_ioctl+0x85/0x200 [<ffffffff8044357f>] thread_return+0x3a/0x62b [<ffffffff8027a620>] do_writepages+0x20/0x40 [<ffffffff802ab10f>] do_ioctl+0x2f/0xa0 [<ffffffff802ab3a0>] vfs_ioctl+0x220/0x2d0 [<ffffffff802ab4e1>] sys_ioctl+0x91/0xb0 [<ffffffff8020bcae>] system_call+0x7e/0x83 Code: 66 89 02 e9 ee fc ff ff 48 8b 95 88 00 00 00 48 8b 45 78 88 RIP [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240 RSP <ffff81007d52fc18> CR2: 0000000000000000 ---[ end trace d485159bd8f95a33 ]--- Michal |
|
From: Anthony L. <an...@co...> - 2008-05-04 22:53:23
|
Dor Laor wrote: > On Sun, 2008-05-04 at 15:21 -0500, Anthony Liguori wrote: > > Patchset looks good and reduces some nasty hacks. It probably also > improves other devices like e1000 et al. > Yeah, we just need to make sure they have proper can_receive handlers. I took a quick look at the e1000 but it wasn't entirely obvious to me how RX packets get queued. AFAICT, the e1000 can_receive handler only reports false when the device isn't initialized so it's likely it's dropping packets. Regards, Anthony Liguori > Cheers, > Dor > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel > |
|
From: nadim k. <na...@kh...> - 2008-05-04 22:53:19
|
On Sunday 04 May 2008 13.19.30 Avi Kivity wrote: > ... > > > I guess it's usage patterns. I'm pretty religious about using -snapshot > > unless I have a very specific reason not to. I have never encountered > > this problem myself. > > Most users cannot use -snapshot for their workloads. and -snapshot does not work with loadvm. > > Xen tries to be very smart about determining whether devices are mounted > > somewhere else or not. > > I'm not talking about being too smart. Just an flock(). That's also what I'd like to see. Make the flock call a standard and have option --exclisove-hda-lock check that no one else has locked the file. This way backwardcompatibility is kept and the one who wants to check still can do it. > > What we really need is a global configuration file so that individual > > users can select these defaults according to what makes sense for them. Any example? |
157 messages has been excluded from this view by a project administrator.
