Re: [kvm-devel] Kernel Oops with kvm 66 running WinXP
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 RIP: >> [] :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:[] [] >> :kvm:x86_emulate_insn+0x3fa/0x4240 >> RSP: 0018:81007d52fc18 EFLAGS: 00010246 >> RAX: 8001003b RBX: RCX: >> RDX: RSI: RDI: 810079c5c000 >> RBP: 810079c5d320 R08: 810079c5d3c0 R09: 0006 >> R10: 0002 R11: R12: 810079c5d368 >> R13: 810079c5d3c0 R14: 8838ab20 R15: 019d1353 >> FS: 40800950(0063) GS:8053e000() knlGS: >> CS: 0010 DS: ES: CR0: 8005003b >> CR2: CR3: 7985a000 CR4: 06e0 >> DR0: DR1: DR2: >> DR3: DR6: 0ff0 DR7: 0400 >> Process qemu-system-x86 (pid: 14776, threadinfo 81007d52e000, task >> 81003f4e6780) >> Stack: 7d52fc74 11fda618 0f399068 810079c5d3c0 >> 81007d52fc94 88368ae0 810079c5c000 >> 810079c5d320 >> Call Trace: >> [] :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 - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Kernel Oops with kvm 66 running WinXP
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 >>> RIP: >>> [] :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:[] [] >>> :kvm:x86_emulate_insn+0x3fa/0x4240 >>> RSP: 0018:81007d52fc18 EFLAGS: 00010246 >>> RAX: 8001003b RBX: RCX: >>> RDX: RSI: RDI: 810079c5c000 >>> RBP: 810079c5d320 R08: 810079c5d3c0 R09: 0006 >>> R10: 0002 R11: R12: 810079c5d368 >>> R13: 810079c5d3c0 R14: 8838ab20 R15: 019d1353 >>> FS: 40800950(0063) GS:8053e000() >>> knlGS: >>> CS: 0010 DS: ES: CR0: 8005003b >>> CR2: CR3: 7985a000 CR4: 06e0 >>> DR0: DR1: DR2: >>> DR3: DR6: 0ff0 DR7: 0400 >>> Process qemu-system-x86 (pid: 14776, threadinfo 81007d52e000, >>> task 81003f4e6780) >>> Stack: 7d52fc74 11fda618 0f399068 >>> 810079c5d3c0 >>> 81007d52fc94 88368ae0 810079c5c000 >>> 810079c5d320 >>> Call Trace: >>> [] :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. - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Kernel Oops with kvm 66 running WinXP
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 >>> RIP: >>> [] :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:[] [] >>> :kvm:x86_emulate_insn+0x3fa/0x4240 >>> RSP: 0018:81007d52fc18 EFLAGS: 00010246 >>> RAX: 8001003b RBX: RCX: >>> RDX: RSI: RDI: 810079c5c000 >>> RBP: 810079c5d320 R08: 810079c5d3c0 R09: 0006 >>> R10: 0002 R11: R12: 810079c5d368 >>> R13: 810079c5d3c0 R14: 8838ab20 R15: 019d1353 >>> FS: 40800950(0063) GS:8053e000() >>> knlGS: >>> CS: 0010 DS: ES: CR0: 8005003b >>> CR2: CR3: 7985a000 CR4: 06e0 >>> DR0: DR1: DR2: >>> DR3: DR6: 0ff0 DR7: 0400 >>> Process qemu-system-x86 (pid: 14776, threadinfo 81007d52e000, >>> task 81003f4e6780) >>> Stack: 7d52fc74 11fda618 0f399068 >>> 810079c5d3c0 >>> 81007d52fc94 88368ae0 810079c5c000 >>> 810079c5d320 >>> Call Trace: >>> [] :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 - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Kernel Oops with kvm 66 running WinXP
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 RIP: [] :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:[] [] :kvm:x86_emulate_insn+0x3fa/0x4240 RSP: 0018:81007d52fc18 EFLAGS: 00010246 RAX: 8001003b RBX: RCX: RDX: RSI: RDI: 810079c5c000 RBP: 810079c5d320 R08: 810079c5d3c0 R09: 0006 R10: 0002 R11: R12: 810079c5d368 R13: 810079c5d3c0 R14: 8838ab20 R15: 019d1353 FS: 40800950(0063) GS:8053e000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 7985a000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process qemu-system-x86 (pid: 14776, threadinfo 81007d52e000, task 81003f4e6780) Stack: 7d52fc74 11fda618 0f399068 810079c5d3c0 81007d52fc94 88368ae0 810079c5c000 810079c5d320 Call Trace: [] :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. - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Kernel Oops with kvm 66 running WinXP
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 RIP:
[] :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
diff --git a/kernel/x86_emulate.c b/kernel/x86_emulate.c
index f2a696d..7f5a99f 100644
--- a/kernel/x86_emulate.c
+++ b/kernel/x86_emulate.c
@@ -1202,6 +1202,13 @@ static inline int writeback(struct x86_emulate_ctxt *ctxt,
switch (c->dst.type) {
case OP_REG:
+
+ if (!c->dst.ptr) {
+ printk("writeback: b %02x mordm %02x\n",
+ c->b, c->modrm);
+ return 0;
+ }
+
/* The 4-byte case *is* correct:
* in 64-bit mode we zero-extend.
*/
-
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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] Use signalfd() in io-thread
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 - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/4] paravirt clock patches
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: > > [EMAIL PROTECTED] ~]# 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/ - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Kernel Oops with kvm 66 running WinXP
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 RIP: >> [] :kvm:x86_emulate_insn+0x3fa/0x4240 > > Please apply the attached patch, and post 'dmesg | grep writeback'. writeback: b 01 mordm e0 M. - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] PATCH: Put QEMU Psuedo-TTY in raw mode
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 <[EMAIL PROTECTED]
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 :|
-
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
Re: [kvm-devel] Kernel Oops with kvm 66 running WinXP
Michal Ludvig wrote:
loaded kvm module (kvm-68)
kvm: emulating exchange as write
Unable to handle kernel NULL pointer dereference at
RIP:
[] :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
diff --git a/kernel/x86_emulate.c b/kernel/x86_emulate.c
index f2a696d..8a96320 100644
--- a/kernel/x86_emulate.c
+++ b/kernel/x86_emulate.c
@@ -677,8 +677,9 @@ static int decode_modrm(struct x86_emulate_ctxt *ctxt,
c->use_modrm_ea = 1;
if (c->modrm_mod == 3) {
- c->modrm_val = *(unsigned long *)
- decode_register(c->modrm_rm, c->regs, c->d & ByteOp);
+ c->modrm_ptr = decode_register(c->modrm_rm,
+ c->regs, c->d & ByteOp);
+ c->modrm_val = *(unsigned long *)c->modrm_ptr;
return rc;
}
@@ -1005,6 +1006,7 @@ done_prefixes:
if ((c->d & ModRM) && c->modrm_mod == 3) {
c->src.type = OP_REG;
c->src.val = c->modrm_val;
+ c->src.ptr = c->modrm_ptr;
break;
}
c->src.type = OP_MEM;
@@ -1049,6 +1051,7 @@ done_prefixes:
if ((c->d & ModRM) && c->modrm_mod == 3) {
c->dst.type = OP_REG;
c->dst.val = c->dst.orig_val = c->modrm_val;
+ c->dst.ptr = c->modrm_ptr;
break;
}
c->dst.type = OP_MEM;
diff --git a/include/asm-x86/kvm_x86_emulate.h b/include/asm-x86/kvm_x86_emulate.h
index d6337f9..b877bbd 100644
--- a/kernel/include/asm-x86/kvm_x86_emulate.h
+++ b/kernel/include/asm-x86/kvm_x86_emulate.h
@@ -135,6 +135,7 @@ struct decode_cache {
u8 modrm_rm;
u8 use_modrm_ea;
unsigned long modrm_ea;
+ void *modrm_ptr;
unsigned long modrm_val;
struct fetch_cache fetch;
};
-
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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Kernel Oops with kvm 66 running WinXP
Avi Kivity wrote: > Michal Ludvig wrote: loaded kvm module (kvm-68) kvm: emulating exchange as write Unable to handle kernel NULL pointer dereference at RIP: [] :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. - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] s390 kvm_virtio.c build error
> 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 <[EMAIL PROTECTED]> This looks almost identical to Rusty's patch. Who is going to send this (or Rustys) patch to Linus? Christian - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Protected mode transitions and big real mode... still an issue
On Sat, 3 May 2008 13:56:56 +0530 Balaji Rao <[EMAIL PROTECTED]> 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 - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Protected mode transitions and big real mode... still an issue
On Monday 05 May 2008 06:10:08 pm Guillaume Thouvenin wrote: > On Sat, 3 May 2008 13:56:56 +0530 > > Balaji Rao <[EMAIL PROTECTED]> 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 - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Protected mode transitions and big real mode... still an issue
Guillaume Thouvenin wrote: > On Sat, 3 May 2008 13:56:56 +0530 > Balaji Rao <[EMAIL PROTECTED]> 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-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] s390 kvm_virtio.c build error
Christian Borntraeger wrote: >> 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 <[EMAIL PROTECTED]> > > This looks almost identical to Rusty's patch. Who is going to send this (or > Rustys) patch to Linus? > I can, but tell me which one. Also, the patch (Heiko's) needs a changelog entry and a signoff. -- error compiling committee.c: too many arguments to function - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] s390 kvm_virtio.c build error
On Mon, 2008-05-05 at 16:00 +0300, Avi Kivity wrote:
> Christian Borntraeger wrote:
> >> 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 <[EMAIL PROTECTED]>
> >
> > This looks almost identical to Rusty's patch. Who is going to send this (or
> > Rustys) patch to Linus?
> >
>
> I can, but tell me which one. Also, the patch (Heiko's) needs a
> changelog entry and a signoff.
I've added Heiko's patch to my patchqueue. But since this is
drivers/s390/kvm this should go in over the kvm.git. See patch below.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
---
Subject: [PATCH] kvm/s390 compile error
From: Heiko Carstens <[EMAIL PROTECTED]>
Fix kvm compile error:
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:
CC drivers/s390/kvm/kvm_virtio.o
drivers/s390/kvm/kvm_virtio.c:224: error: unknown field 'feature' specified in
initializer
drivers/s390/kvm/kvm_virtio.c:224: warning: initialization from incompatible
pointer type
make[3]: *** [drivers/s390/kvm/kvm_virtio.o] Error 1
Cc: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/s390/kvm/kvm_virtio.c | 40 +++-
1 file changed, 23 insertions(+), 17 deletions(-)
diff -urpN linux-2.6/drivers/s390/kvm/kvm_virtio.c
linux-2.6-patched/drivers/s390/kvm/kvm_virtio.c
--- linux-2.6/drivers/s390/kvm/kvm_virtio.c 2008-05-05 13:20:45.0
+0200
+++ linux-2.6-patched/drivers/s390/kvm/kvm_virtio.c 2008-05-05
13:20:48.0 +0200
@@ -78,27 +78,32 @@ 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;
+ for (i = 0; i < min(desc->feature_len * 8, 32); i++)
+ if (in_features[i / 8] & (1 << (i % 8)))
+ features |= (1 << i);
+ return features;
+}
- features = kvm_vq_features(desc);
- if (!(features[fbit / 8] & (1 << (fbit % 8
- return false;
+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;
- /*
-* 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;
+ 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 +226,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,
-
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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] s390 kvm_virtio.c build error
[EMAIL PROTECTED] wrote: > I've added Heiko's patch to my patchqueue. But since this is > drivers/s390/kvm this should go in over the kvm.git. See patch below. Acked-by: Carsten Otte <[EMAIL PROTECTED]> - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Protected mode transitions and big real mode... still an issue
On Mon, May 5, 2008 at 3:57 PM, Anthony Liguori <[EMAIL PROTECTED]> wrote: > 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. > WinXP fails with the patch applied too. Ubuntu 7.10 live CD and FreeDOS don't boot but complain about instruction mov 0x11,sreg not being emulated. - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 4/4] Only select once per-main_loop iteration (v2)
QEMU is rather aggressive about exhausting the wait period when selecting.
This is fine when the wait period is low and when there is significant delays
in-between selects as it improves IO throughput.
With the IO thread, there is a very small delay between selects and our wait
period for select is very large. This patch changes main_loop_wait to only
select once before doing the various other things in the main loop. This
generally improves responsiveness of things like SDL but also improves
individual file descriptor throughput quite dramatically.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index e16b261..6a90e68 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -423,24 +423,6 @@ void qemu_kvm_notify_work(void)
fprintf(stderr, "failed to notify io thread\n");
}
-static int received_signal;
-
-/* QEMU relies on periodically breaking out of select via EINTR to poll for IO
- and timer signals. Since we're now using a file descriptor to handle
- signals, select() won't be interrupted by a signal. We need to forcefully
- break the select() loop when a signal is received hence
- kvm_check_received_signal(). */
-
-int kvm_check_received_signal(void)
-{
-if (received_signal) {
- received_signal = 0;
- return 1;
-}
-
-return 0;
-}
-
/* If we have signalfd, we mask out the signals we want to handle and then
* use signalfd to listen for them. We rely on whatever the current signal
* handler is to dispatch the signals when we receive them.
@@ -474,8 +456,6 @@ static void sigfd_handler(void *opaque)
pthread_cond_signal(&qemu_aio_cond);
}
}
-
-received_signal = 1;
}
/* Used to break IO thread out of select */
@@ -497,8 +477,6 @@ static void io_thread_wakeup(void *opaque)
offset += len;
}
-
-received_signal = 1;
}
int kvm_main_loop(void)
diff --git a/qemu/qemu-kvm.h b/qemu/qemu-kvm.h
index e1e461a..34aabd2 100644
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -114,15 +114,6 @@ static inline void kvm_sleep_end(void)
kvm_mutex_lock();
}
-int kvm_check_received_signal(void);
-
-static inline int kvm_received_signal(void)
-{
-if (kvm_enabled())
- return kvm_check_received_signal();
-return 0;
-}
-
#if !defined(SYS_signalfd)
struct signalfd_siginfo {
uint32_t ssi_signo;
diff --git a/qemu/vl.c b/qemu/vl.c
index e9f0ca4..6935a82 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7946,23 +7946,18 @@ void main_loop_wait(int timeout)
slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
}
#endif
- moreio:
ret = qemu_select(nfds + 1, &rfds, &wfds, &xfds, &tv);
if (ret > 0) {
IOHandlerRecord **pioh;
-int more = 0;
for(ioh = first_io_handler; ioh != NULL; ioh = ioh->next) {
if (!ioh->deleted && ioh->fd_read && FD_ISSET(ioh->fd, &rfds)) {
ioh->fd_read(ioh->opaque);
-if (!ioh->fd_read_poll || ioh->fd_read_poll(ioh->opaque))
-more = 1;
-else
+if (!(ioh->fd_read_poll && ioh->fd_read_poll(ioh->opaque)))
FD_CLR(ioh->fd, &rfds);
}
if (!ioh->deleted && ioh->fd_write && FD_ISSET(ioh->fd, &wfds)) {
ioh->fd_write(ioh->opaque);
-more = 1;
}
}
@@ -7976,8 +7971,6 @@ void main_loop_wait(int timeout)
} else
pioh = &ioh->next;
}
-if (more && !kvm_received_signal())
-goto moreio;
}
#if defined(CONFIG_SLIRP)
if (slirp_inited) {
-
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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/4] Use signalfd() in io-thread (v2)
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().
I've tested Windows and Linux guests with SMP without seeing an obvious
regressions.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/kvm-compatfd.c b/qemu/kvm-compatfd.c
index 1b030ba..3c2be28 100644
--- a/qemu/kvm-compatfd.c
+++ b/qemu/kvm-compatfd.c
@@ -15,6 +15,100 @@
#include "qemu-kvm.h"
#include
+#include
+
+struct sigfd_compat_info
+{
+sigset_t mask;
+int fd;
+};
+
+static void *sigwait_compat(void *opaque)
+{
+struct sigfd_compat_info *info = opaque;
+int err;
+
+sigprocmask(SIG_BLOCK, &info->mask, NULL);
+
+do {
+ siginfo_t siginfo;
+
+ kvm_sleep_begin();
+ err = sigwaitinfo(&info->mask, &siginfo);
+ kvm_sleep_end();
+
+ if (err == -1 && errno == EINTR)
+ continue;
+
+ if (err > 0) {
+ char buffer[128];
+ size_t offset = 0;
+
+ memcpy(buffer, &err, sizeof(err));
+ while (offset < sizeof(buffer)) {
+ ssize_t len;
+
+ len = write(info->fd, buffer + offset,
+ sizeof(buffer) - offset);
+ if (len == -1 && errno == EINTR)
+ continue;
+
+ if (len <= 0) {
+ err = -1;
+ break;
+ }
+
+ offset += len;
+ }
+ }
+} while (err >= 0);
+
+return NULL;
+}
+
+static int kvm_signalfd_compat(const sigset_t *mask)
+{
+pthread_attr_t attr;
+pthread_t tid;
+struct sigfd_compat_info *info;
+int fds[2];
+
+info = malloc(sizeof(*info));
+if (info == NULL) {
+ errno = ENOMEM;
+ return -1;
+}
+
+if (pipe(fds) == -1) {
+ free(info);
+ return -1;
+}
+
+memcpy(&info->mask, mask, sizeof(*mask));
+info->fd = fds[1];
+
+pthread_attr_init(&attr);
+pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
+
+pthread_create(&tid, &attr, sigwait_compat, info);
+
+pthread_attr_destroy(&attr);
+
+return fds[0];
+}
+
+int kvm_signalfd(const sigset_t *mask)
+{
+#if defined(SYS_signalfd)
+int ret;
+
+ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8);
+if (!(ret == -1 && errno == ENOSYS))
+ return ret;
+#endif
+
+return kvm_signalfd_compat(mask);
+}
int kvm_eventfd(int *fds)
{
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 7134e56..0ea03f8 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -12,6 +12,9 @@ int kvm_allowed = 1;
int kvm_irqchip = 1;
int kvm_pit = 1;
+#include "qemu-common.h"
+#include "console.h"
+
#include
#include "hw/hw.h"
#include "sysemu.h"
@@ -40,14 +43,6 @@ __thread struct vcpu_info *vcpu;
static int qemu_system_ready;
-struct qemu_kvm_signal_table {
-sigset_t sigset;
-sigset_t negsigset;
-};
-
-static struct qemu_kvm_signal_table io_signal_table;
-static struct qemu_kvm_signal_table vcpu_signal_table;
-
#define SIG_IPI (SIGRTMIN+4)
struct vcpu_info {
@@ -172,37 +167,23 @@ static int has_work(CPUState *env)
return kvm_arch_has_work(env);
}
-static int kvm_process_signal(int si_signo)
-{
-struct sigaction sa;
-
-switch (si_signo) {
-case SIGUSR2:
-pthread_cond_signal(&qemu_aio_cond);
-break;
-case SIGALRM:
-case SIGIO:
-sigaction(si_signo, NULL, &sa);
-sa.sa_handler(si_signo);
-break;
-}
-
-return 1;
-}
-
-static int kvm_eat_signal(struct qemu_kvm_signal_table *waitset, CPUState *env,
- int timeout)
+static int kvm_eat_signal(CPUState *env, int timeout)
{
struct timespec ts;
int r, e, ret = 0;
siginfo_t siginfo;
+sigset_t waitset;
ts.tv_sec = timeout / 1000;
ts.tv_nsec = (timeout % 1000) * 100;
-r = sigtimedwait(&waitset->sigset, &siginfo, &ts);
+sigemptyset(&waitset);
+sigaddset(&waitset, SIG_IPI);
+
+r = sigtimedwait(&waitset, &siginfo, &ts);
if (r == -1 && (errno == EAGAIN || errno == EINTR) && !timeout)
return 0;
e = errno;
+
pthread_mutex_lock(&qemu_mutex);
if (env && vcpu)
cpu_single_env = vcpu->env;
@@ -211,7 +192,7 @@ static int kvm_eat_signal(struct qemu_kvm_signal_table
*waitset, CPUState *env,
exit(1);
}
if (r != -1)
-ret = kvm_process_signal(siginfo.si_signo);
+ ret = 1;
if (env && vcpu_info[env->cpu_index].stop) {
vcpu_info[env->cpu_index].stop = 0;
@@ -227,14 +208,13 @@ static int kvm_eat_signal(struct qemu_kvm_signal_table
*waitset, CPUState *env,
static void kvm_eat_signals(CPUState *env, int timeout)
{
int r = 0;
-struct qemu_kvm_signal_table *waitset = &vcpu_signal_table;
-while (kvm_eat_s
[kvm-devel] [PATCH 3/4] Interrupt io thread in qemu_set_fd_handler2 (v2)
The select() in the IO thread may wait a long time before rebuilding the
fd set. Whenever we do something that changes the fd set, we should interrupt
the IO thread.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/vl.c b/qemu/vl.c
index 1192759..e9f0ca4 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -260,6 +260,16 @@ static int event_pending = 1;
#define TFR(expr) do { if ((expr) != -1) break; } while (errno == EINTR)
+/* KVM runs the main loop in a separate thread. If we update one of the lists
+ * that are polled before or after select(), we need to make sure to break out
+ * of the select() to ensure the new item is serviced.
+ */
+static void main_loop_break(void)
+{
+if (kvm_enabled())
+ qemu_kvm_notify_work();
+}
+
void decorate_application_name(char *appname, int max_len)
{
if (kvm_enabled())
@@ -5680,6 +5690,7 @@ int qemu_set_fd_handler2(int fd,
ioh->opaque = opaque;
ioh->deleted = 0;
}
+main_loop_break();
return 0;
}
@@ -7606,8 +7617,7 @@ void qemu_bh_schedule(QEMUBH *bh)
if (env) {
cpu_interrupt(env, CPU_INTERRUPT_EXIT);
}
-if (kvm_enabled())
-qemu_kvm_notify_work();
+main_loop_break();
}
void qemu_bh_cancel(QEMUBH *bh)
-
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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/4] Replace SIGUSR1 in io-thread with eventfd() (v2)
It's a little odd to use signals to raise a notification on a file descriptor
when we can just work directly with a file descriptor instead. This patch
converts the SIGUSR1 based notification in the io-thread to instead use an
eventfd file descriptor. If eventfd isn't available, we use a pipe() instead.
The benefit of using eventfd is that multiple notifications will be batched
into a signal IO event.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 2316c92..db6912e 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -203,7 +203,7 @@ CPPFLAGS+=-I$(SRC_PATH)/tcg/sparc
endif
ifeq ($(USE_KVM), 1)
-LIBOBJS+=qemu-kvm.o
+LIBOBJS+=qemu-kvm.o kvm-compatfd.o
endif
ifdef CONFIG_SOFTFLOAT
LIBOBJS+=fpu/softfloat.o
diff --git a/qemu/kvm-compatfd.c b/qemu/kvm-compatfd.c
new file mode 100644
index 000..1b030ba
--- /dev/null
+++ b/qemu/kvm-compatfd.c
@@ -0,0 +1,33 @@
+/*
+ * signalfd/eventfd compatibility
+ *
+ * Copyright IBM, Corp. 2008
+ *
+ * Authors:
+ * Anthony Liguori <[EMAIL PROTECTED]>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "qemu-kvm.h"
+
+#include
+
+int kvm_eventfd(int *fds)
+{
+#if defined(SYS_eventfd)
+int ret;
+
+ret = syscall(SYS_eventfd, 0);
+if (ret >= 0) {
+ fds[0] = fds[1] = ret;
+ return 0;
+} else if (!(ret == -1 && errno == ENOSYS))
+ return ret;
+#endif
+
+return pipe(fds);
+}
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 9a9bf59..7134e56 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -15,6 +15,8 @@ int kvm_pit = 1;
#include
#include "hw/hw.h"
#include "sysemu.h"
+#include "qemu-common.h"
+#include "console.h"
#include "qemu-kvm.h"
#include
@@ -61,6 +63,7 @@ struct vcpu_info {
} vcpu_info[256];
pthread_t io_thread;
+static int io_thread_fd = -1;
static inline unsigned long kvm_get_thread_id(void)
{
@@ -213,7 +216,7 @@ static int kvm_eat_signal(struct qemu_kvm_signal_table
*waitset, CPUState *env,
if (env && vcpu_info[env->cpu_index].stop) {
vcpu_info[env->cpu_index].stop = 0;
vcpu_info[env->cpu_index].stopped = 1;
- pthread_kill(io_thread, SIGUSR1);
+ qemu_kvm_notify_work();
}
pthread_mutex_unlock(&qemu_mutex);
@@ -418,7 +421,6 @@ static void qemu_kvm_init_signal_tables(void)
kvm_add_signal(&io_signal_table, SIGIO);
kvm_add_signal(&io_signal_table, SIGALRM);
-kvm_add_signal(&io_signal_table, SIGUSR1);
kvm_add_signal(&io_signal_table, SIGUSR2);
kvm_add_signal(&vcpu_signal_table, SIG_IPI);
@@ -440,8 +442,51 @@ int kvm_init_ap(void)
void qemu_kvm_notify_work(void)
{
-if (io_thread)
-pthread_kill(io_thread, SIGUSR1);
+uint64_t value = 1;
+char buffer[8];
+size_t offset = 0;
+
+if (io_thread_fd == -1)
+ return;
+
+memcpy(buffer, &value, sizeof(value));
+
+while (offset < 8) {
+ ssize_t len;
+
+ len = write(io_thread_fd, buffer + offset, 8 - offset);
+ if (len == -1 && errno == EINTR)
+ continue;
+
+ if (len <= 0)
+ break;
+
+ offset += len;
+}
+
+if (offset != 8)
+ fprintf(stderr, "failed to notify io thread\n");
+}
+
+/* Used to break IO thread out of select */
+static void io_thread_wakeup(void *opaque)
+{
+int fd = (unsigned long)opaque;
+char buffer[8];
+size_t offset = 0;
+
+while (offset < 8) {
+ ssize_t len;
+
+ len = read(fd, buffer + offset, 8 - offset);
+ if (len == -1 && errno == EINTR)
+ continue;
+
+ if (len <= 0)
+ break;
+
+ offset += len;
+}
}
/*
@@ -452,8 +497,20 @@ void qemu_kvm_notify_work(void)
int kvm_main_loop(void)
{
+int fds[2];
+
io_thread = pthread_self();
qemu_system_ready = 1;
+
+if (kvm_eventfd(fds) == -1) {
+ fprintf(stderr, "failed to create eventfd\n");
+ return -errno;
+}
+
+qemu_set_fd_handler2(fds[0], NULL, io_thread_wakeup, NULL,
+(void *)(unsigned long)fds[0]);
+
+io_thread_fd = fds[1];
pthread_mutex_unlock(&qemu_mutex);
pthread_cond_broadcast(&qemu_system_cond);
diff --git a/qemu/qemu-kvm.h b/qemu/qemu-kvm.h
index 024a653..8cd63e6 100644
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -97,4 +97,6 @@ extern kvm_context_t kvm_context;
#define qemu_kvm_pit_in_kernel() (0)
#endif
+int kvm_eventfd(int *fds);
+
#endif
-
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-devel@lists.sourceforge.net
https
Re: [kvm-devel] [PATCH 1/3] Use signalfd() in io-thread
Anthony Liguori wrote: >> >> Please break the SIGUSR1 changes into a separate patch. Ditto with >> *fd syscall compat. > > Done. I didn't make the syscall compat stuff separate patches because > that would break bisect on older hosts. However, I did split it up > logically between the remove sigusr1 patch and the signalfd patch. > Not if you placed the compat patch before the use (e.g. a patch which adds kvm_signalfd() but no uses). -- error compiling committee.c: too many arguments to function - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] PATCH: Put QEMU Psuedo-TTY in raw mode
Daniel P. Berrange wrote: > 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 > > > [...] I've just merged qemu-svn into kvm, unfortunately two revisions short of 4338. Once my tree passes the regression tests, I'll merge again so this patch is included. -- error compiling committee.c: too many arguments to function - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/4] paravirt clock patches
On Mon, May 05, 2008 at 09:47:59AM +0200, Gerd Hoffmann wrote: > 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: > > > > [EMAIL PROTECTED] ~]# 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? F8 host, recent kvm-userspace.git (so with IO thread), recent kvm.git (plus your patches), haven't tried 2x but I think 4x is not necessary to reproduce the problem. > A quick test with xenner (which has a separate I/O thread) didn't show > anything unusual. Going investigate ... Give a pure kvm guest a try, its pretty easy to reproduce. - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 01 of 11] mmu-notifier-core
On Fri, May 02, 2008 at 05:05:04PM +0200, Andrea Arcangeli wrote: > # HG changeset patch > # User Andrea Arcangeli <[EMAIL PROTECTED]> > # Date 1209740175 -7200 > # Node ID 1489529e7b53d3f2dab8431372aa4850ec821caa > # Parent 5026689a3bc323a26d33ad882c34c4c9c9a3ecd8 > mmu-notifier-core I upgraded to the latest mmu notifier patch & hit a deadlock. (Sorry - I should have seen this earlier but I haven't tracked the last couple of patches). The GRU does the registration/deregistration of mmu notifiers from mmap/munmap. At this point, the mmap_sem is already held writeable. I hit a deadlock in mm_lock. A quick fix would be to do one of the following: - move the mmap_sem locking to the caller of the [de]registration routines. Since the first/last thing done in mm_lock/mm_unlock is to acquire/release mmap_sem, this change does not cause major changes. - add a flag to mmu_notifier_[un]register routines to indicate if mmap_sem is already locked. I've temporarily deleted the mm_lock locking of mmap_sem and am continuing to test. More later --- jack - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0 of 2] [RESEND] [PowerPC] Fix setting memory for bamboo board model
These patches fell through the cracks. This set of patches fixes setting memory for PowerPC bamboo board model. Besides just setting memory in qemu, you must also set it in the device tree. This sets the memory in the device tree so that it can be something other then the hard coded memory size of 144MB. Signed-off-by: Jerone Young <[EMAIL PROTECTED]> - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2 of 2] Fix memory defined in device tree by declaring it dynamically for bamboo board model
# HG changeset patch
# User Jerone Young <[EMAIL PROTECTED]>
# Date 1210003411 18000
# Branch merge
# Node ID c455452c9b217abed8a2e6147bbeb91f33ff1799
# Parent cf3ccc3add69052aade695c746151b1cb8812252
Fix memory defined in device tree by declaring it dynamically for bamboo board
model
This fixes a issue where the amount of memory is not properly being defined in
the device tree. It currently is hardcoded for 144MB. The result is that if you
specify a memory size below the hardcoded size, the guest crashes. This patch
now dynamically changes the device tree to the memory value specified.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
--- a/qemu/hw/ppc440_bamboo.c
+++ b/qemu/hw/ppc440_bamboo.c
@@ -50,6 +50,7 @@ void bamboo_init(ram_addr_t ram_size, in
int i=0, k=0;
uint32_t cpu_freq;
uint32_t timebase_freq;
+ uint32_t mem_reg_property[]={0, 0, ram_size};
printf("%s: START\n", __func__);
@@ -73,6 +74,7 @@ void bamboo_init(ram_addr_t ram_size, in
printf("WARNING: %i MB left over memory is ram\n",
bytes_to_mb((int)tmp_ram_size));
ram_size -= tmp_ram_size;
+ mem_reg_property[2] = ram_size;
}
/* Setup CPU */
@@ -159,6 +161,8 @@ void bamboo_init(ram_addr_t ram_size, in
/* manipulate device tree in memory */
dt_cell(fdt, "/cpus/[EMAIL PROTECTED]", "clock-frequency", cpu_freq);
dt_cell(fdt, "/cpus/[EMAIL PROTECTED]", "timebase-frequency",
timebase_freq);
+ dt_cell_multi(fdt, "/memory", "reg", mem_reg_property,
+ sizeof(mem_reg_property));
dt_cell(fdt, "/chosen", "linux,initrd-start", initrd_base);
dt_cell(fdt, "/chosen", "linux,initrd-end",
(initrd_base + initrd_size));
-
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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1 of 2] Add function dt_cell_multi to hw/device_tree.c
# HG changeset patch
# User Jerone Young <[EMAIL PROTECTED]>
# Date 1210003408 18000
# Branch merge
# Node ID cf3ccc3add69052aade695c746151b1cb8812252
# Parent 97e439fdd4e91c3fb1ef9055f073add55084d69f
Add function dt_cell_multi to hw/device_tree.c
This patch adds function dt_cell_multi to allow for manipulation of device tree
properties that contain mulitiple 32bit values.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/qemu/hw/device_tree.c b/qemu/hw/device_tree.c
--- a/qemu/hw/device_tree.c
+++ b/qemu/hw/device_tree.c
@@ -162,6 +162,21 @@ void dt_cell(void *fdt, char *node_path,
}
}
+/* This function is to manipulate a cell with multiple values */
+void dt_cell_multi(void *fdt, char *node_path, char *property,
+ uint32_t *val_array, int size)
+{
+ int offset;
+ int ret;
+ offset = get_offset_of_node(fdt, node_path);
+ ret = fdt_setprop(fdt, offset, property, val_array, size);
+ if (ret < 0) {
+ printf("Unable to set device tree property '%s'\n",
+ property);
+ exit(1);
+ }
+}
+
void dt_string(void *fdt, char *node_path, char *property,
char *string)
{
diff --git a/qemu/hw/device_tree.h b/qemu/hw/device_tree.h
--- a/qemu/hw/device_tree.h
+++ b/qemu/hw/device_tree.h
@@ -19,6 +19,8 @@ void dump_device_tree_to_file(void *fdt,
void dump_device_tree_to_file(void *fdt, char *filename);
void dt_cell(void *fdt, char *node_path, char *property,
uint32_t val);
+void dt_cell_multi(void *fdt, char *node_path, char *property,
+ uint32_t *val_array, int size);
void dt_string(void *fdt, char *node_path, char *property,
char *string);
void dt_node(void *fdt, char *node_parent_path, char *name);
-
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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH]: Fake MSR_K7 performance counters
Attached is a patch that fixes a guest crash when booting older Linux kernels. The problem stems from the fact that we are currently emulating MSR_K7_EVNTSEL[0-3], but not emulating MSR_K7_PERFCTR[0-3]. Because of this, setup_k7_watchdog() in the Linux kernel receives a GPF when it attempts to write into MSR_K7_PERFCTR, which causes an OOPs. The patch fixes it by just "fake" emulating the appropriate MSRs, throwing away the data in the process. This causes the NMI watchdog to not actually work, but it's not such a big deal in a virtualized environment. When we get a write to one of these counters, we printk_ratelimit() a warning. I decided to print it out for all writes, even if the data is 0; it doesn't seem to make sense to me to special case when data == 0. Tested by myself on a RHEL-4 guest, and Joerg Roedel on a Windows XP 64-bit guest. Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 5528121..dc91b09 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -1312,16 +1312,19 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 data) case MSR_K7_EVNTSEL1: case MSR_K7_EVNTSEL2: case MSR_K7_EVNTSEL3: + case MSR_K7_PERFCTR0: + case MSR_K7_PERFCTR1: + case MSR_K7_PERFCTR2: + case MSR_K7_PERFCTR3: /* - * only support writing 0 to the performance counters for now - * to make Windows happy. Should be replaced by a real - * performance counter emulation later. + * Just discard all writes to the performance counters; this + * should keep both older linux and windows 64-bit guests + * happy */ - if (data != 0) - goto unhandled; + pr_unimpl(vcpu, "unimplemented perfctr wrmsr: 0x%x data 0x%llx\n", ecx, data); + break; default: - unhandled: return kvm_set_msr_common(vcpu, ecx, data); } return 0; - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 01 of 11] mmu-notifier-core
On Mon, May 05, 2008 at 11:21:13AM -0500, Jack Steiner wrote: > The GRU does the registration/deregistration of mmu notifiers from > mmap/munmap. > At this point, the mmap_sem is already held writeable. I hit a deadlock > in mm_lock. It'd been better to know about this detail earlier, but frankly this is a minor problem, the important thing is we all agree together on the more difficult parts ;). > A quick fix would be to do one of the following: > > - move the mmap_sem locking to the caller of the [de]registration > routines. > Since the first/last thing done in mm_lock/mm_unlock is to > acquire/release mmap_sem, this change does not cause major changes. I don't like this solution very much. Nor GRU nor KVM will call mmu_notifier_register inside the mmap_sem protected sections, so I think the default mmu_notifier_register should be smp safe by itself without requiring additional locks to be artificially taken externally (especially because the need for mmap_sem in write mode is a very mmu_notifier internal detail). > - add a flag to mmu_notifier_[un]register routines to indicate > if mmap_sem is already locked. The interface would change like this: #define MMU_NOTIFIER_REGISTER_MMAP_SEM (1<<0) void mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm, unsigned long mmu_notifier_flags); A third solution is to add: /* * This must can be called instead of mmu_notifier_register after * taking the mmap_sem in write mode (read mode isn't enough). */ void __mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm); Do you still prefer the bitflag or you prefer __mmu_notifier_register. It's ok either ways, except __mmu_notifier_reigster could be removed in a backwards compatible way, the bitflag can't. > I've temporarily deleted the mm_lock locking of mmap_sem and am continuing to > test. More later Sure! In the meantime go ahead this way. Another very minor change I've been thinking about is to make ->release not mandatory. It happens that with KVM ->release isn't strictly required because after mm_users reaches 0, no guest could possibly run anymore. So I'm using ->release only for debugging by placing -1UL in the root shadow pagetable, to be sure ;). So because at least one user won't strictly require ->release being consistent in having all method optional may be nicer. Alternatively we could make them all mandatory and if somebody doesn't need one of the methods it should implement it as a dummy function. Both ways have pros and cons, but they don't make any difference to us in practice. If I've to change the patch for the mmap_sem taken during registration I may as well cleanup this minor bit. Also note the rculist.h patch you sent earlier won't work against mainline so I can't incorporate it in my patchset, Andrew will have to apply it as mmu-notifier-core-mm after incorporating mmu-notifier-core into -mm. Until a new update is released, mmu-notifier-core v15 remains ok for merging, no known bugs, here we're talking about a new and simple feature and a tiny cleanup that nobody can notice anyway. - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 01 of 11] mmu-notifier-core
On Mon, May 05, 2008 at 07:14:34PM +0200, Andrea Arcangeli wrote: > On Mon, May 05, 2008 at 11:21:13AM -0500, Jack Steiner wrote: > > The GRU does the registration/deregistration of mmu notifiers from > > mmap/munmap. > > At this point, the mmap_sem is already held writeable. I hit a deadlock > > in mm_lock. > > It'd been better to know about this detail earlier, Agree. My apologies... I should have caught it. > but frankly this > is a minor problem, the important thing is we all agree together on > the more difficult parts ;). > > > A quick fix would be to do one of the following: > > > > - move the mmap_sem locking to the caller of the [de]registration > > routines. > > Since the first/last thing done in mm_lock/mm_unlock is to > > acquire/release mmap_sem, this change does not cause major changes. > > I don't like this solution very much. Nor GRU nor KVM will call > mmu_notifier_register inside the mmap_sem protected sections, so I > think the default mmu_notifier_register should be smp safe by itself > without requiring additional locks to be artificially taken externally > (especially because the need for mmap_sem in write mode is a very > mmu_notifier internal detail). > > > - add a flag to mmu_notifier_[un]register routines to indicate > > if mmap_sem is already locked. > > The interface would change like this: > > #define MMU_NOTIFIER_REGISTER_MMAP_SEM (1<<0) > void mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm, > unsigned long mmu_notifier_flags); That works... > > A third solution is to add: > > /* > * This must can be called instead of mmu_notifier_register after > * taking the mmap_sem in write mode (read mode isn't enough). > */ > void __mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm); > > Do you still prefer the bitflag or you prefer > __mmu_notifier_register. It's ok either ways, except > __mmu_notifier_reigster could be removed in a backwards compatible > way, the bitflag can't. > > > I've temporarily deleted the mm_lock locking of mmap_sem and am continuing > > to > > test. More later __mmu_notifier_register/__mmu_notifier_unregister seems like a better way to go, although either is ok. > > Sure! In the meantime go ahead this way. > > Another very minor change I've been thinking about is to make > ->release not mandatory. It happens that with KVM ->release isn't > strictly required because after mm_users reaches 0, no guest could > possibly run anymore. So I'm using ->release only for debugging by > placing -1UL in the root shadow pagetable, to be sure ;). So because > at least one user won't strictly require ->release being consistent in > having all method optional may be nicer. Alternatively we could make > them all mandatory and if somebody doesn't need one of the methods it > should implement it as a dummy function. Both ways have pros and cons, > but they don't make any difference to us in practice. If I've to > change the patch for the mmap_sem taken during registration I may as > well cleanup this minor bit. Let me finish my testing. At one time, I did not use ->release but with all the locking & teardown changes, I need to do some reverification. --- jack - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 0 of 2] [RESEND] [PowerPC] Fix setting memory for bamboo board model
On Monday 05 May 2008 11:04:52 Jerone Young wrote: > These patches fell through the cracks. > > This set of patches fixes setting memory for PowerPC bamboo board model. Besides just setting memory in qemu, you must also set it in the device tree. This sets the memory in the device tree so that it can be something other then the hard coded memory size of 144MB. > > Signed-off-by: Jerone Young <[EMAIL PROTECTED]> Acked-by: Hollis Blanchard <[EMAIL PROTECTED]> Avi, please apply to kvm-userspace; thanks. -- Hollis Blanchard IBM Linux Technology Center - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 01 of 11] mmu-notifier-core
On Mon, May 05, 2008 at 12:25:06PM -0500, Jack Steiner wrote:
> Agree. My apologies... I should have caught it.
No problem.
> __mmu_notifier_register/__mmu_notifier_unregister seems like a better way to
> go, although either is ok.
If you also like __mmu_notifier_register more I'll go with it. The
bitflags seems like a bit of overkill as I can't see the need of any
other bitflag other than this one and they also can't be removed as
easily in case you'll find a way to call it outside the lock later.
> Let me finish my testing. At one time, I did not use ->release but
> with all the locking & teardown changes, I need to do some reverification.
If you didn't implement it you shall apply this patch but you shall
read carefully the comment I written that covers that usage case.
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -29,10 +29,25 @@ struct mmu_notifier_ops {
/*
* Called either by mmu_notifier_unregister or when the mm is
* being destroyed by exit_mmap, always before all pages are
-* freed. It's mandatory to implement this method. This can
-* run concurrently with other mmu notifier methods and it
+* freed. This can run concurrently with other mmu notifier
+* methods (the ones invoked outside the mm context) and it
* should tear down all secondary mmu mappings and freeze the
-* secondary mmu.
+* secondary mmu. If this method isn't implemented you've to
+* be sure that nothing could possibly write to the pages
+* through the secondary mmu by the time the last thread with
+* tsk->mm == mm exits.
+*
+* As side note: the pages freed after ->release returns could
+* be immediately reallocated by the gart at an alias physical
+* address with a different cache model, so if ->release isn't
+* implemented because all memory accesses through the
+* secondary mmu implicitly are terminated by the time the
+* last thread of this mm quits, you've also to be sure that
+* speculative hardware operations can't allocate dirty
+* cachelines in the cpu that could not be snooped and made
+* coherent with the other read and write operations happening
+* through the gart alias address, leading to memory
+* corruption.
*/
void (*release)(struct mmu_notifier *mn,
struct mm_struct *mm);
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -59,7 +59,8 @@ void __mmu_notifier_release(struct mm_st
* from establishing any more sptes before all the
* pages in the mm are freed.
*/
- mn->ops->release(mn, mm);
+ if (mn->ops->release)
+ mn->ops->release(mn, mm);
srcu_read_unlock(&mm->mmu_notifier_mm->srcu, srcu);
spin_lock(&mm->mmu_notifier_mm->lock);
}
@@ -251,7 +252,8 @@ void mmu_notifier_unregister(struct mmu_
* guarantee ->release is called before freeing the
* pages.
*/
- mn->ops->release(mn, mm);
+ if (mn->ops->release)
+ mn->ops->release(mn, mm);
srcu_read_unlock(&mm->mmu_notifier_mm->srcu, srcu);
} else
spin_unlock(&mm->mmu_notifier_mm->lock);
-
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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 01 of 11] mmu-notifier-core
On Mon, May 05, 2008 at 08:34:05PM +0200, Andrea Arcangeli wrote: > On Mon, May 05, 2008 at 12:25:06PM -0500, Jack Steiner wrote: > > Agree. My apologies... I should have caught it. > > No problem. > > > __mmu_notifier_register/__mmu_notifier_unregister seems like a better way to > > go, although either is ok. > > If you also like __mmu_notifier_register more I'll go with it. The > bitflags seems like a bit of overkill as I can't see the need of any > other bitflag other than this one and they also can't be removed as > easily in case you'll find a way to call it outside the lock later. > > > Let me finish my testing. At one time, I did not use ->release but > > with all the locking & teardown changes, I need to do some reverification. I finished testing & everything looks good. I do use the ->release callout but mainly as a performance hint that teardown is in progress & that TLB flushing is no longer needed. (GRU TLB entries are tagged with a task-specific ID that will not be reused until a full TLB purge is done. This eliminates the requirement to purge at task-exit.) Normally, a notifier is registered when a GRU segment is mmaped, and unregistered when the segment is unmapped. Well behaved tasks will not have a GRU or a notifier when exit starts. If a task fails to unmap a GRU segment, they still exist at the start of exit. On the ->release callout, I set a flag in the container of my mmu_notifier that exit has started. As VMA are cleaned up, TLB flushes are skipped because of the flag is set. When the GRU VMA is deleted, I free my structure containing the notifier. I _think_ works. Do you see any problems? I should also mention that I have an open-coded function that possibly belongs in mmu_notifier.c. A user is allowed to have multiple GRU segments. Each GRU has a couple of data structures linked to the VMA. All, however, need to share the same notifier. I currently open code a function that scans the notifier list to determine if a GRU notifier already exists. If it does, I update a refcnt & use it. Otherwise, I register a new one. All of this is protected by the mmap_sem. Just in case I mangled the above description, I'll attach a copy of the GRU mmuops code. --- jack z Description: Unix compressed data - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFC] [VTD][patch 0/3] vt-d support for pci passthrough
Following three patches contains vt-d support for pci passthrough. It contains diff's base on Amit's 4/22 passthrough tree. The hardware environment used for this work is an Intel Weybridge system (Q35). The passthrough device is an E1000 NIC. I'm still using irqhook mechanism for interrupt injection as I had problem with irqchip machanism. Following is the command line I used to start the guest. /usr/local/bin/qemu-system-x86_64 -boot c -hda /etc/xen/fc5_32.img -m 256 -net none -pcidevice e1000/01:00.0-16 -no-kvm-irqchip Remaining tasks include: 1) Generated vtd.o with kvm-intel.ko instead of kvm.ko. 2) Make iommu hooks in generic code to be non-Intel specific Let me know of your feedbacks. Thanks. Allen - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFC] [VTD][patch 1/3] vt-d support for pci passthrough: kvm-vtd--kernel.patch
Kvm kernel changes.
Signed-off-by: Allen M Kay <[EMAIL PROTECTED]>
--
arch/x86/kvm/Makefile |2
arch/x86/kvm/vtd.c | 183
+
arch/x86/kvm/x86.c |7 +
include/asm-x86/kvm_host.h |3
include/asm-x86/kvm_para.h |1
include/linux/kvm_host.h |6 +
virt/kvm/kvm_main.c|3
7 files changed, 204 insertions(+), 1 deletion(-)
--
diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index c97d35c..b1057fb 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86/kvm/Makefile
@@ -12,7 +12,7 @@ EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
kvm-objs := $(common-objs) x86.o mmu.o x86_emulate.o i8259.o irq.o
lapic.o \
i8254.o
obj-$(CONFIG_KVM) += kvm.o
-kvm-intel-objs = vmx.o
+kvm-intel-objs = vmx.o vtd.o
obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
kvm-amd-objs = svm.o
obj-$(CONFIG_KVM_AMD) += kvm-amd.o
diff --git a/arch/x86/kvm/vtd.c b/arch/x86/kvm/vtd.c
new file mode 100644
index 000..9a080b5
--- /dev/null
+++ b/arch/x86/kvm/vtd.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright (c) 2006, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * Copyright (C) 2006-2008 Intel Corporation
+ * Author: Allen M. Kay <[EMAIL PROTECTED]>
+ * Author: Weidong Han <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+//#define DEBUG
+
+#define DEFAULT_DOMAIN_ADDRESS_WIDTH 48
+
+struct dmar_drhd_unit * dmar_find_matched_drhd_unit(struct pci_dev
*dev);
+struct dmar_domain * iommu_alloc_domain(struct intel_iommu *iommu);
+void iommu_free_domain(struct dmar_domain *domain);
+int domain_init(struct dmar_domain *domain, int guest_width);
+int domain_context_mapping(struct dmar_domain *d,
+ struct pci_dev *pdev);
+int domain_page_mapping(struct dmar_domain *domain, dma_addr_t iova,
+ u64 hpa, size_t size, int prot);
+void detach_domain_for_dev(struct dmar_domain *domain, u8 bus, u8
devfn);
+struct dmar_domain * find_domain(struct pci_dev *pdev);
+
+
+int kvm_iommu_map_pages(struct kvm *kvm,
+ gfn_t base_gfn, unsigned long npages)
+{
+ unsigned long gpa;
+ struct page *page;
+ hpa_t hpa;
+ int j, write;
+ struct vm_area_struct *vma;
+
+ if (!kvm->arch.domain)
+ return 1;
+
+ gpa = base_gfn << PAGE_SHIFT;
+ page = gfn_to_page(kvm, base_gfn);
+ hpa = page_to_phys(page);
+
+ printk(KERN_DEBUG "kvm_iommu_map_page: gpa = %lx\n", gpa);
+ printk(KERN_DEBUG "kvm_iommu_map_page: hpa = %llx\n", hpa);
+ printk(KERN_DEBUG "kvm_iommu_map_page: size = %lx\n",
+ npages*PAGE_SIZE);
+
+ for (j = 0; j < npages; j++) {
+ gpa += PAGE_SIZE;
+ page = gfn_to_page(kvm, gpa >> PAGE_SHIFT);
+ hpa = page_to_phys(page);
+ domain_page_mapping(kvm->arch.domain, gpa, hpa,
PAGE_SIZE,
+ DMA_PTE_READ | DMA_PTE_WRITE);
+ vma = find_vma(current->mm, gpa);
+ if (!vma)
+ return 1;
+ write = (vma->vm_flags & VM_WRITE) != 0;
+ get_user_pages(current, current->mm, gpa,
+ PAGE_SIZE, write, 0, NULL, NULL);
+ }
+ return 0;
+}
+EXPORT_SYMBOL_GPL(kvm_iommu_map_pages);
+
+static int kvm_iommu_map_memslots(struct kvm *kvm)
+{
+ int i, status;
+ for (i = 0; i < kvm->nmemslots; i++) {
+ status = kvm_iommu_map_pages(kvm,
kvm->memslots[i].base_gfn,
+ kvm->memslots[i].npages);
+ if (status)
+ return status;
+ }
+ return 0;
+}
+
+int kvm_iommu_map_guest(struct kvm *kvm,
+ struct kvm_pci_passthrough_dev *pci_pt_dev)
+{
+ struct dmar_drhd_unit *drhd;
+ struct dmar_domain *domain;
+ struct intel_iommu *iommu;
+ struct pci_dev *pdev = NULL;
+
+ printk(KERN_DEBUG "kvm_iommu_map_guest: host bdf = %x:%x:%x\n",
+ pci_pt_dev->host.busnr,
+ PCI_SLOT(pci_pt_dev->host.devfn),
+ PCI_FUNC(pci_pt_dev->host.devfn));
+
+ for_each_pci_dev(pdev) {
+ if ((pdev->bus->number == pci_pt_dev->host.busnr) &&
+ (pdev->devfn == pci_pt_dev->host.devfn))
+
[kvm-devel] [RFC] [VTD][patch 2/3] vt-d support for pci passthrough: kvm-vtd-user.patch
Kvm-user-mode patch. Still todo: move vt.d to kvm-intel.ko module. Signed-off-by: Allen M Kay <[EMAIL PROTECTED]> - Kbuild |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - diff --git a/kernel/Kbuild b/kernel/Kbuild index e3e97ab..7455605 100644 --- a/kernel/Kbuild +++ b/kernel/Kbuild @@ -1,7 +1,7 @@ EXTRA_CFLAGS := -I$(src)/include -include $(src)/external-module-compat.h obj-m := kvm.o kvm-intel.o kvm-amd.o kvm-objs := kvm_main.o x86.o mmu.o x86_emulate.o anon_inodes.o irq.o i8259.o \ -lapic.o ioapic.o preempt.o i8254.o +lapic.o ioapic.o preempt.o i8254.o vtd.o ifeq ($(CONFIG_KVM_TRACE),y) kvm-objs += kvm_trace.o endif - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFC] [VTD][patch 3/3] vt-d support for pci passthrough: kvm-intel-iommu.patch
Intel-iommu driver changes for kvm vt-d support. Important changes are
in intel-iommu.c. The rest of the changes are for moving intel-iommu.h
and iova.h from drivers/pci directory to include/linux directory.
Signed-off-by: Allen M Kay <[EMAIL PROTECTED]>
b/drivers/pci/dmar.c |4
b/drivers/pci/intel-iommu.c | 26 ++-
b/drivers/pci/iova.c |2
b/include/linux/intel-iommu.h | 344
++
b/include/linux/iova.h| 52 ++
drivers/pci/intel-iommu.h | 344
--
drivers/pci/iova.h| 52 --
7 files changed, 416 insertions(+), 408 deletions(-)
diff --git a/drivers/pci/dmar.c b/drivers/pci/dmar.c
index f941f60..a58a5b0 100644
--- a/drivers/pci/dmar.c
+++ b/drivers/pci/dmar.c
@@ -26,8 +26,8 @@
#include
#include
-#include "iova.h"
-#include "intel-iommu.h"
+#include
+#include
#undef PREFIX
#define PREFIX "DMAR:"
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 4cb949f..bfa888b 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -31,8 +31,8 @@
#include
#include
#include
-#include "iova.h"
-#include "intel-iommu.h"
+#include
+#include
#include /* force_iommu in this header in x86-64*/
#include
#include
@@ -1056,7 +1056,7 @@ static void free_iommu(struct intel_iommu *iommu)
kfree(iommu);
}
-static struct dmar_domain * iommu_alloc_domain(struct intel_iommu
*iommu)
+struct dmar_domain * iommu_alloc_domain(struct intel_iommu *iommu)
{
unsigned long num;
unsigned long ndomains;
@@ -1086,8 +1086,9 @@ static struct dmar_domain *
iommu_alloc_domain(struct intel_iommu *iommu)
return domain;
}
+EXPORT_SYMBOL_GPL(iommu_alloc_domain);
-static void iommu_free_domain(struct dmar_domain *domain)
+void iommu_free_domain(struct dmar_domain *domain)
{
unsigned long flags;
@@ -1095,6 +1096,7 @@ static void iommu_free_domain(struct dmar_domain
*domain)
clear_bit(domain->id, domain->iommu->domain_ids);
spin_unlock_irqrestore(&domain->iommu->lock, flags);
}
+EXPORT_SYMBOL_GPL(iommu_free_domain);
static struct iova_domain reserved_iova_list;
static struct lock_class_key reserved_alloc_key;
@@ -1160,7 +1162,7 @@ static inline int guestwidth_to_adjustwidth(int
gaw)
return agaw;
}
-static int domain_init(struct dmar_domain *domain, int guest_width)
+int domain_init(struct dmar_domain *domain, int guest_width)
{
struct intel_iommu *iommu;
int adjust_width, agaw;
@@ -1196,6 +1198,7 @@ static int domain_init(struct dmar_domain *domain,
int guest_width)
__iommu_flush_cache(iommu, domain->pgd, PAGE_SIZE_4K);
return 0;
}
+EXPORT_SYMBOL_GPL(domain_init);
static void domain_exit(struct dmar_domain *domain)
{
@@ -1258,7 +1261,7 @@ static int domain_context_mapping_one(struct
dmar_domain *domain,
return 0;
}
-static int
+int
domain_context_mapping(struct dmar_domain *domain, struct pci_dev
*pdev)
{
int ret;
@@ -1289,6 +1292,7 @@ domain_context_mapping(struct dmar_domain *domain,
struct pci_dev *pdev)
return domain_context_mapping_one(domain,
tmp->bus->number, tmp->devfn);
}
+EXPORT_SYMBOL_GPL(domain_context_mapping);
static int domain_context_mapped(struct dmar_domain *domain,
struct pci_dev *pdev)
@@ -1321,7 +1325,7 @@ static int domain_context_mapped(struct
dmar_domain *domain,
tmp->bus->number, tmp->devfn);
}
-static int
+int
domain_page_mapping(struct dmar_domain *domain, dma_addr_t iova,
u64 hpa, size_t size, int prot)
{
@@ -1351,13 +1355,15 @@ domain_page_mapping(struct dmar_domain *domain,
dma_addr_t iova,
}
return 0;
}
+EXPORT_SYMBOL_GPL(domain_page_mapping);
-static void detach_domain_for_dev(struct dmar_domain *domain, u8 bus,
u8 devfn)
+void detach_domain_for_dev(struct dmar_domain *domain, u8 bus, u8
devfn)
{
clear_context_table(domain->iommu, bus, devfn);
iommu_flush_context_global(domain->iommu, 0);
iommu_flush_iotlb_global(domain->iommu, 0);
}
+EXPORT_SYMBOL_GPL(detach_domain_for_dev);
static void domain_remove_dev_info(struct dmar_domain *domain)
{
@@ -1397,6 +1403,7 @@ find_domain(struct pci_dev *pdev)
return info->domain;
return NULL;
}
+EXPORT_SYMBOL_GPL(find_domain);
static int dmar_pci_device_match(struct pci_dev *devices[], int cnt,
struct pci_dev *dev)
@@ -1415,7 +1422,7 @@ static int dmar_pci_device_match(struct pci_dev
*devices[], int cnt,
return 0;
}
-static struct dmar_drhd_unit *
+struct dmar_drhd_unit *
dmar_find_matched_drhd_unit(struct pci_dev *dev)
{
struct dmar_drhd_unit *drhd = NULL;
@@ -1428,6 +1435,7 @@ dmar_find_matched_drhd_unit(struct pci_dev *dev)
return NULL;
}
+EXPORT_SYMBOL_GPL(dmar_find_matched_drhd_unit);
/* domain is initializ
Re: [kvm-devel] [patch 0/3] QEMU/KVM: add support for 128 PCI slots (v2)
On May 4, 2008, at 9:56 AM, Avi Kivity wrote: > Marcelo Tosatti wrote: >> Add three PCI bridges to support 128 slots. >> >> Changes since v1: >> - Remove I/O address range "support" (so standard PCI I/O space is >> used). >> - Verify that there's no special quirks for 82801 PCI bridge. >> - Introduce separate flat IRQ mapping function for non-SPARC targets. >> >> > > I've cooled off on the 128 slot stuff, mainly because most real hosts > don't have them. An unusual configuration will likely lead to > problems > as most guest OSes and workloads will not have been tested thoroughly > with them. This is more of a "let's do this conditionally" than a "let's not do it" reason imho. > - it requires a large number of interrupts, which are difficult to > provide, and which it is hard to ensure all OSes support. MSI is > relatively new. We could just as well extend the device layout to have every device be attached to one virtual IOAPIC pin, so we'd have like 128 / 4 = 32 IOAPICs in the system and one interrupt for each device. > - is only a few interrupts are available, then each interrupt requires > scanning a large number of queues This case should be rare, basically only existent with OSs that don't support APIC properly. > If we are to do this, then we need better tests than "80 disks show > up". True. > The alternative approach of having the virtio block device control > up to > 16 disks allows having those 80 disks with just 5 slots (and 5 > interrupts). This is similar to the way traditional SCSI controllers > behave, and so should not surprise the guest OS. The one thing I'm actually really missing here is use cases. What are we doing this for? And further along the line, are there other approaches to the problems for which this was supposed to be a solution? Maybe someone can raise a case where it's not virtblk / virtnet. Alex - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 0/3] QEMU/KVM: add support for 128 PCI slots (v2)
Avi Kivity wrote: > Marcelo Tosatti wrote: > >> Add three PCI bridges to support 128 slots. >> >> Changes since v1: >> - Remove I/O address range "support" (so standard PCI I/O space is used). >> - Verify that there's no special quirks for 82801 PCI bridge. >> - Introduce separate flat IRQ mapping function for non-SPARC targets. >> >> >> > > I've cooled off on the 128 slot stuff, mainly because most real hosts > don't have them. An unusual configuration will likely lead to problems > as most guest OSes and workloads will not have been tested thoroughly > with them. > > - it requires a large number of interrupts, which are difficult to > provide, and which it is hard to ensure all OSes support. MSI is > relatively new. > - is only a few interrupts are available, then each interrupt requires > scanning a large number of queues > > If we are to do this, then we need better tests than "80 disks show up". > > The alternative approach of having the virtio block device control up to > 16 disks allows having those 80 disks with just 5 slots (and 5 > interrupts). This is similar to the way traditional SCSI controllers > behave, and so should not surprise the guest OS. > If you have a single virtio-blk device that shows up as 8 functions, we could achieve the same thing. We can cheat with the interrupt handlers to avoid cache line bouncing too. Plus, we can use PCI hotplug so we don't have to reinvent a new hotplug mechanism. I'm inclined to think that ring sharing isn't as useful as it seems as long as we don't have indirect scatter gather lists. Regards, Anthony Liguori - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 0/3] QEMU/KVM: add support for 128 PCI slots (v2)
On May 4, 2008, at 9:56 AM, Avi Kivity wrote: > Marcelo Tosatti wrote: >> Add three PCI bridges to support 128 slots. >> >> Changes since v1: >> - Remove I/O address range "support" (so standard PCI I/O space is >> used). >> - Verify that there's no special quirks for 82801 PCI bridge. >> - Introduce separate flat IRQ mapping function for non-SPARC targets. >> >> > > I've cooled off on the 128 slot stuff, mainly because most real hosts > don't have them. An unusual configuration will likely lead to > problems > as most guest OSes and workloads will not have been tested thoroughly > with them. This is more of a "let's do this conditionally" than a "let's not do it" reason imho. > - it requires a large number of interrupts, which are difficult to > provide, and which it is hard to ensure all OSes support. MSI is > relatively new. We could just as well extend the device layout to have every device be attached to one virtual IOAPIC pin, so we'd have like 128 / 4 = 32 IOAPICs in the system and one interrupt for each device. > - is only a few interrupts are available, then each interrupt requires > scanning a large number of queues This case should be rare, basically only existent with OSs that don't support APIC properly. > If we are to do this, then we need better tests than "80 disks show > up". True. > The alternative approach of having the virtio block device control > up to > 16 disks allows having those 80 disks with just 5 slots (and 5 > interrupts). This is similar to the way traditional SCSI controllers > behave, and so should not surprise the guest OS. The one thing I'm actually really missing here is use cases. What are we doing this for? And further along the line, are there other approaches to the problems for which this was supposed to be a solution? Maybe someone can raise a case where it's not virtblk / virtnet. Alex - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Unknown symbol in module
With today's tip, I cannot insert PAE KVM modules. Lots of unknown symbols have been reported while inserting kvm.ko. error inserting '/usr/kvm/kvm.ko': -1 Unknown symbol in module dmesg: kvm_intel: Unknown symbol kvm_set_cr4 kvm_intel: Unknown symbol kvm_set_cr0 kvm_intel: Unknown symbol kvm_set_cr8 kvm_intel: Unknown symbol kvm_lapic_enabled kvm_intel: Unknown symbol kvm_mmu_page_fault kvm_intel: Unknown symbol kvm_mmu_reset_context kvm_intel: Unknown symbol kvm_queue_exception_e kvm_intel: Unknown symbol kvm_emulate_cpuid kvm_intel: Unknown symbol kvm_vcpu_init kvm_intel: Unknown symbol gfn_to_hva kvm_intel: Unknown symbol kvm_set_msr_common kvm_intel: Unknown symbol kvm_mmu_set_base_ptes kvm_intel: Unknown symbol kvm_cpu_get_interrupt kvm_intel: Unknown symbol kvm_emulate_pio kvm_intel: Unknown symbol kvm_mmu_set_mask_ptes kvm_intel: Unknown symbol kvm_is_error_hva kvm: Unknown symbol kvm_div64_u64 kvm: emulating preempt notifiers; do not benchmark on this machine loaded kvm module (kvm-67-2059-g9cebc1e) kvm: Unknown symbol kvm_div64_u64 - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1958464 ] "Unknown symbol in module" loading kvm.ko
Bugs item #1958464, was opened at 2008-05-06 14:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958464&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: "Unknown symbol in module" loading kvm.ko Initial Comment: With today's commits, kvm.git 630741928b4a7eeff27e134d7ba7bc2fc2c764c5 and kvm-userspace.git 77c9148ba4a89a8dc4ab2ecf525c2de8604ea8c3. , I cannot insert PAE KVM modules. Lots of unknown symbols have been reported while inserting kvm.ko. error inserting '/usr/kvm/kvm.ko': -1 Unknown symbol in module dmesg: kvm_intel: Unknown symbol kvm_set_cr4 kvm_intel: Unknown symbol kvm_set_cr0 kvm_intel: Unknown symbol kvm_set_cr8 kvm_intel: Unknown symbol kvm_lapic_enabled kvm_intel: Unknown symbol kvm_mmu_page_fault kvm_intel: Unknown symbol kvm_mmu_reset_context kvm_intel: Unknown symbol kvm_queue_exception_e kvm_intel: Unknown symbol kvm_emulate_cpuid kvm_intel: Unknown symbol kvm_vcpu_init kvm_intel: Unknown symbol gfn_to_hva kvm_intel: Unknown symbol kvm_set_msr_common kvm_intel: Unknown symbol kvm_mmu_set_base_ptes kvm_intel: Unknown symbol kvm_cpu_get_interrupt kvm_intel: Unknown symbol kvm_emulate_pio kvm_intel: Unknown symbol kvm_mmu_set_mask_ptes kvm_intel: Unknown symbol kvm_is_error_hva kvm: Unknown symbol kvm_div64_u64 kvm: emulating preempt notifiers; do not benchmark on this machine loaded kvm module (kvm-67-2059-g9cebc1e) kvm: Unknown symbol kvm_div64_u64 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958464&group_id=180599 - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1958467 ] Fail to save restore and live migrate on 32e platform
Bugs item #1958467, was opened at 2008-05-06 14:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958467&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: Fail to save restore and live migrate on 32e platform Initial Comment: Environment: Host OS: RHEL5U1 ia32e Commits: 630741928b4a7eeff27e134d7ba7bc2fc2c764c5-77c9148ba4a89a8dc4ab2ecf525c2de8604ea8c3 Hardware:Platform Woodcrest CPU 4 Memory size 8G' Bug detailed description: -- Fail to save restore and live migrate on 32e platform. When restore the guest, the new qemu disappeared, host console print: qemu: warning: error while loading state for instance 0x0 of device 'cpu' Migration failed rc=215 Reproduce steps: 1.use qcow based image to boot a guest: qemu-img create -b /share/xvs/img/app/ia32p_UP.img -f qcow2 /share/xvs/var/sr qemu-system-x86_64 -m 256 -monitor pty -net nic,macaddr=00:16:3e:35:1c:97,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/sr 2.ctrl+alt+2 switch to qemu monitor and save the guest migrate file:///share/xvs/var/sr123 3.restore qemu-system-x86_64 -m 256 -net nic,macaddr=00:16:3e:35:1c:97,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/sr -incoming file:///share/xvs/var/sr123 Current result: Expected result: -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958467&group_id=180599 - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
