You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(33) |
Nov
(325) |
Dec
(320) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(484) |
Feb
(438) |
Mar
(407) |
Apr
(713) |
May
(831) |
Jun
(806) |
Jul
(1023) |
Aug
(1184) |
Sep
(1118) |
Oct
(1461) |
Nov
(1224) |
Dec
(1042) |
2008 |
Jan
(1449) |
Feb
(1110) |
Mar
(1428) |
Apr
(1643) |
May
(682) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Mendy <tha...@HI...> - 2008-04-13 20:25:56
|
With this, all the babes will flock to you. http://www.opeoteae.com/ |
From: Avi K. <av...@qu...> - 2008-04-13 16:35:46
|
Avi Kivity wrote: > Avi Kivity wrote: >> >>> @@ -3944,11 +3950,13 @@ static void vcpu_kick_intr(void *info) >>> void kvm_vcpu_kick(struct kvm_vcpu *vcpu) >>> { >>> int ipi_pcpu = vcpu->cpu; >>> + int cpu = get_cpu(); >>> >>> if (waitqueue_active(&vcpu->wq)) { >>> wake_up_interruptible(&vcpu->wq); >>> ++vcpu->stat.halt_wakeup; >>> } >>> - if (vcpu->guest_mode) >>> + if (vcpu->guest_mode && vcpu->cpu != cpu) >>> smp_call_function_single(ipi_pcpu, vcpu_kick_intr, vcpu, 0, >>> 0); >>> + put_cpu(); >>> } >>> >> >> Looks like a no-op now, as vcpu_kick_intr() does nothing and >> smp_call_function_single() won't force an exit if vcpu->cpu == cpu, >> so I dropped this hunk. >> > > Oh, I see the reason now: the irq stuff now happens with irqs disabled > which annoys smp_call_function_single(). Well, I'd like to avoid all > this irq-disabled processing, so I'm looking at an alternate fix using > a new KVM_REQ_EVAL_IRQ. > !@%$#@%, we can't move guest irq processing out of the critical section since we can't commit to irq delivery (we may have to deliver an exception instead). I'll apply your patch as is, and will look at disentangling this later. -- error compiling committee.c: too many arguments to function |
From: Anders <ma...@fl...> - 2008-04-13 16:30:32
|
Marcelo Tosatti wrote: > With SIGIO enabled on stdio, there's no need to wakeup the thread > performing IO every 30ms. > > Signed-off-by: Marcelo Tosatti <mto...@re...> > > Index: kvm-userspace.io/qemu/vl.c > =================================================================== > --- kvm-userspace.io.orig/qemu/vl.c > +++ kvm-userspace.io/qemu/vl.c > @@ -5640,6 +5640,7 @@ static void dumb_display_init(DisplaySta > ds->dpy_update = dumb_update; > ds->dpy_resize = dumb_resize; > ds->dpy_refresh = dumb_refresh; > + ds->gui_timer_interval = 1000; > } > > /***********************************************************/ > Why even the 1000ms timer? I was proposing to just set ds->dpy_refresh to NULL for the dumb_display, but hit the qemu-devel dead-end. http://lists.gnu.org/archive/html/qemu-devel/2008-01/msg00374.html Do you see a problem with that approach? If yes, then that problem is probably currently present in the unconnected VNC case, as that one now disables the periodic timer completely. Cheers, Anders. |
From: Avi K. <av...@qu...> - 2008-04-13 16:08:01
|
Avi Kivity wrote: > >> @@ -3944,11 +3950,13 @@ static void vcpu_kick_intr(void *info) >> void kvm_vcpu_kick(struct kvm_vcpu *vcpu) >> { >> int ipi_pcpu = vcpu->cpu; >> + int cpu = get_cpu(); >> >> if (waitqueue_active(&vcpu->wq)) { >> wake_up_interruptible(&vcpu->wq); >> ++vcpu->stat.halt_wakeup; >> } >> - if (vcpu->guest_mode) >> + if (vcpu->guest_mode && vcpu->cpu != cpu) >> smp_call_function_single(ipi_pcpu, vcpu_kick_intr, vcpu, 0, 0); >> + put_cpu(); >> } >> > > Looks like a no-op now, as vcpu_kick_intr() does nothing and > smp_call_function_single() won't force an exit if vcpu->cpu == cpu, so > I dropped this hunk. > Oh, I see the reason now: the irq stuff now happens with irqs disabled which annoys smp_call_function_single(). Well, I'd like to avoid all this irq-disabled processing, so I'm looking at an alternate fix using a new KVM_REQ_EVAL_IRQ. -- error compiling committee.c: too many arguments to function |
From: Alexey E. <al...@gm...> - 2008-04-13 15:24:16
|
On Sun, Apr 13, 2008 at 1:49 PM, Michal Ludvig <ml...@lo...> wrote: > Hi all, > > in short: CentOS 5 guest (32bit) crashes when I run "reboot" in the VM > with qemu message: > kvm_run: failed entry, reason 65535 > kvm_run returned -8 > > In dmesg is this message: > kvm: 23769: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop > > Details: > KVM 65 > Host is openSUSE 10.3 with my own 2.6.24, 64 bit > Guest is CentOS 5.1 with 2.6.18-53.1.14.el5, 32 bit > GCC 4.2.1 for module, GCC 3.3.3 for qemu > CPU "AMD Athlon(tm) 64 X2 Dual Core Processor 5600+" > > Everything works fine, except that I can't reboot the guest. In VNC it > says "md: stopping devices" and then Qemu exits with: > kvm_run: failed entry, reason 65535 > kvm_run returned -8 > > IIRC reboot used to work with kvm-64 > > If you need more information let me know. > > Michal Yea, this is known bug, that I reported to Avi recently. I hope it will be fixed soon. -- -Alexey Eromenko "Technologov" |
From: Avi K. <av...@qu...> - 2008-04-13 15:05:39
|
Marcelo Tosatti wrote: > On Fri, Apr 11, 2008 at 01:59:35PM -0500, Anthony Liguori wrote: > >> With the IO thread, shouldn't we be striving to perform the select()s >> within the IO thread itself to completely avoid the need to use SIGIO at >> all? >> > > Fully agree. Problem with it are the fundamental changes in qemu that > are required (and the difficulty merging those in qemu). > > One is tempted to use pselect() to temporarily unblock the signals while waiting. This has two problems, though: one, pselect() is emulated in libc with older kernels, and this emulation has an (unavoidable) race. Two, I think pselect() will deliver the signal in addition to returning, which we want to avoid. Not sure about this though. -- error compiling committee.c: too many arguments to function |
From: Avi K. <av...@qu...> - 2008-04-13 15:01:44
|
Marcelo Tosatti wrote: > Address comments from Avi: > > - fold mp_state into a structure > - IOW/IOR markers for ioctl definitions > - return -ENOSYS if extension is not supported > > Applied all, thanks. -- error compiling committee.c: too many arguments to function |
From: Avi K. <av...@qu...> - 2008-04-13 14:59:03
|
Marcelo Tosatti wrote: > So userspace can save/restore the mpstate during migration. Applied, thanks. I also added public #defines for the possible values. -- error compiling committee.c: too many arguments to function |
From: Michal L. <ml...@lo...> - 2008-04-13 14:41:26
|
Hi all, in short: CentOS 5 guest (32bit) crashes when I run "reboot" in the VM with qemu message: kvm_run: failed entry, reason 65535 kvm_run returned -8 In dmesg is this message: kvm: 23769: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop Details: KVM 65 Host is openSUSE 10.3 with my own 2.6.24, 64 bit Guest is CentOS 5.1 with 2.6.18-53.1.14.el5, 32 bit GCC 4.2.1 for module, GCC 3.3.3 for qemu CPU "AMD Athlon(tm) 64 X2 Dual Core Processor 5600+" Everything works fine, except that I can't reboot the guest. In VNC it says "md: stopping devices" and then Qemu exits with: kvm_run: failed entry, reason 65535 kvm_run returned -8 IIRC reboot used to work with kvm-64 If you need more information let me know. Michal |
From: Avi K. <av...@qu...> - 2008-04-13 14:24:04
|
Jerone Young wrote: > - I am resending this patch removing ia64. It apprently fell through the cracks. > > Don't compile kvm_*_pit() on architectures whose currently supported platforms do not contain a PIT. > > Signed-off-by: Hollis Blanchard <ho...@us...> > Signed-off-by: Jerone Young <jy...@us...> > > diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h > --- a/libkvm/libkvm.h > +++ b/libkvm/libkvm.h > @@ -549,6 +549,7 @@ int kvm_pit_in_kernel(kvm_context_t kvm) > > #ifdef KVM_CAP_PIT > > +#if defined(__i386__) || defined(__x86_64__) > /*! > * \brief Get in kernel PIT of the virtual domain > * > @@ -569,6 +570,7 @@ int kvm_get_pit(kvm_context_t kvm, struc > * \param s PIT state of the virtual domain > */ > int kvm_set_pit(kvm_context_t kvm, struct kvm_pit_state *s); > +#endif > > #endif Patch is okay, but doesn't match the description at all. Is this what you intended to send? -- error compiling committee.c: too many arguments to function |
From: 钟文辉 <she...@12...> - 2008-04-13 14:23:52
|
各位老总:您们好! 诚祝:您们在2008年里;有鼠不尽的快乐!鼠不尽的收获!鼠不尽的钞票! 鼠不尽的幸福!鼠不尽的美满生活!愿: 您们阖家欢乐!幸福安康! 我是(深圳市珊湖岛进出口有限公司)的负责人;可以提供:出口报关单, 核销单等等一系列手续;代理:出口报关,商检,境内外运输......等等;还可 以代办:出口欧盟许可证,欧盟产地证;并且还有(广州国际贸易交易会)的摊 位可以转让;有意者请来邮件或来电联系;谢谢合作! 电话:0755-81153047。 传真:0755-81172940。 手机:15817477278。 联系人:钟文辉。 此致: 敬礼! |
From: 钟文辉 <she...@12...> - 2008-04-13 14:12:51
|
各位老总:您们好! 诚祝:您们在2008年里;有鼠不尽的快乐!鼠不尽的收获!鼠不尽的钞票! 鼠不尽的幸福!鼠不尽的美满生活!愿: 您们阖家欢乐!幸福安康! 我是(深圳市珊湖岛进出口有限公司)的负责人;可以提供:出口报关单, 核销单等等一系列手续;代理:出口报关,商检,境内外运输......等等;还可 以代办:出口欧盟许可证,欧盟产地证;并且还有(广州国际贸易交易会)的摊 位可以转让;有意者请来邮件或来电联系;谢谢合作! 电话:0755-81153047。 传真:0755-81172940。 手机:15817477278。 联系人:钟文辉。 此致: 敬礼! |
From: Dor L. <dor...@qu...> - 2008-04-13 13:16:12
|
On Thu, 2008-04-10 at 11:48 +0300, Amit Shah wrote: > We can assign a device from the host machine to a guest. > > A new command-line option, -pcidevice is added. > For example, to invoke it for an Ethernet device sitting at > PCI bus:dev.fn 04:08.0 with host IRQ 18, use this: > > -pcidevice Ethernet/04:08.0-18 > > The host ethernet driver is to be removed before doing the passthrough. > > If kvm uses the in-kernel irqchip, interrupts are routed to > the guest via the kvm module (accompanied kernel changes are necessar). > If -no-kvm-irqchip is used, the 'irqhook' module, also included here, > is to be used. > IMO we can drop the pci pass through support in userspace and only keep the in-kenel chip path. Normally we do want the option of running w/o kernel devices but it's only to test for regressions against userspace. In this case it's all new code so there is no point to compare, it's just lots of complicated code (userspace apic, irqhook module) that only helpful for qemu. Since it's not likely qemu will merge it, let's stick with the main path. Comments? Dor > Signed-off-by: Amit Shah <ami...@qu...> > --- > Makefile | 10 +- > irqhook/Kbuild | 3 + > irqhook/Makefile | 25 ++ > irqhook/irqhook_main.c | 215 ++++++++++++++ > kernel/Makefile | 4 + > libkvm/libkvm-x86.c | 14 +- > libkvm/libkvm.h | 24 ++ > qemu/Makefile.target | 1 + > qemu/hw/apic.c | 2 + > qemu/hw/isa.h | 2 + > qemu/hw/pc.c | 4 + > qemu/hw/pci-passthrough.c | 677 +++++++++++++++++++++++++++++++++++++++++++++ > qemu/hw/pci-passthrough.h | 102 +++++++ > qemu/hw/pci.c | 11 + > qemu/hw/pci.h | 1 + > qemu/hw/piix_pci.c | 19 ++ > qemu/vl.c | 16 + > tools/pci_barsize.c | 53 ++++ > tools/pci_mmio.c | 82 ++++++ > 19 files changed, 1260 insertions(+), 5 deletions(-) > |
From: SourceForge.net <no...@so...> - 2008-04-13 11:21:12
|
Bugs item #1941302, was opened at 2008-04-13 19:21 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=1941302&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: Cannot boot guests with hugetlbfs Initial Comment: I meet problem to get hugetlbfs work on my test box. If i added "--mem-path" to qemu, the guest will always fail to boot with the error messages below printed on qemu console: ########################################### ata0 master: ATA-0 Hard-Disk ( 0 MBytes) ata1 master: ATAPI-0 Device Booting from Hard Disk ..... Booting from Hard Disk failed: could not read the boot disk ########################################## And I checked my system, hugepages has been enabled. [root@vt-dp8 ~]# grep -i huge /proc/meminfo HugePages_Total: 500 HugePages_Free: 496 HugePages_Rsvd: 0 Hugepagesize: 2048 kB [root@vt-dp8 ~]# mount /dev/sda1 on / type ext3 (rw) none on /dev/shm type tmpfs (rw,size=4G) nodev on /hugepages type hugetlbfs (rw) /dev/sda3 on /share type ext2 (rw) /dev/sda2 on /mnt/sda2 type ext3 (rw) The command i am using: qemu -m 256 -monitor pty -net nic,macaddr=00:16:3e:48:d4:aa,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /dev/sda --mem-path /hugepages/ If I remove "--mem-path", the guest can be booted up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1941302&group_id=180599 |
From: Avi K. <av...@qu...> - 2008-04-13 10:08:21
|
Marcelo Tosatti wrote: > On Fri, Apr 11, 2008 at 03:18:19PM +0300, Avi Kivity wrote: > >> kvm_vcpu_kick() can be called from nonatomic contexts, so the vcpu->cpu >> == cpu check is dangerous (and will warn on preemptible kernels, no?) >> > > Doh, right. How's this. > > ----------- > > KVM: fix kvm_vcpu_kick vs __vcpu_run race > > There is a window open between testing of pending IRQ's > and assignment of guest_mode in __vcpu_run. > > Injection of IRQ's can race with __vcpu_run as follows: > > CPU0 CPU1 > kvm_x86_ops->run() > vcpu->guest_mode = 0 SET_IRQ_LINE ioctl > .. > kvm_x86_ops->inject_pending_irq > kvm_cpu_has_interrupt() > > apic_test_and_set_irr() > kvm_vcpu_kick > if (vcpu->guest_mode) > send_ipi() > > vcpu->guest_mode = 1 > > So move guest_mode=1 assignment before ->inject_pending_irq, and make > sure that it won't reorder after it. > > > Applied, but this > @@ -3944,11 +3950,13 @@ static void vcpu_kick_intr(void *info) > void kvm_vcpu_kick(struct kvm_vcpu *vcpu) > { > int ipi_pcpu = vcpu->cpu; > + int cpu = get_cpu(); > > if (waitqueue_active(&vcpu->wq)) { > wake_up_interruptible(&vcpu->wq); > ++vcpu->stat.halt_wakeup; > } > - if (vcpu->guest_mode) > + if (vcpu->guest_mode && vcpu->cpu != cpu) > smp_call_function_single(ipi_pcpu, vcpu_kick_intr, vcpu, 0, 0); > + put_cpu(); > } > Looks like a no-op now, as vcpu_kick_intr() does nothing and smp_call_function_single() won't force an exit if vcpu->cpu == cpu, so I dropped this hunk. -- error compiling committee.c: too many arguments to function |
From: Avi K. <av...@qu...> - 2008-04-13 09:47:46
|
Carsten Otte wrote: > Avi Kivity wrote: >>> @@ -765,6 +766,7 @@ void kvm_vcpu_block(struct kvm_vcpu *vcp >>> >> >> >> This breaks ia64 (and shouldn't s390 use this too?) >>> * We will block until either an interrupt or a signal wakes us up >>> */ >>> while (!kvm_cpu_has_interrupt(vcpu) >>> + && !kvm_cpu_has_pending_timer(vcpu) >>> >> >> I guess the fix is to stub this out for the other archs. > > We don't use that, we have our own implementation of vcpu_block. Why? -- error compiling committee.c: too many arguments to function |
From: Avi K. <av...@qu...> - 2008-04-13 09:28:24
|
Marcelo Tosatti wrote: > On Fri, Apr 11, 2008 at 03:12:41PM +0300, Avi Kivity wrote: > > >> This breaks ia64 (and shouldn't s390 use this too?) >> >>> * We will block until either an interrupt or a signal wakes us up >>> */ >>> while (!kvm_cpu_has_interrupt(vcpu) >>> + && !kvm_cpu_has_pending_timer(vcpu) >>> >>> >> I guess the fix is to stub this out for the other archs. >> > > Agreed. How's this. > > Better :); applied. -- error compiling committee.c: too many arguments to function |
From: Avi K. <av...@qu...> - 2008-04-13 08:36:26
|
Amit Shah wrote: > Passthrough devices are host machine PCI devices which have > been handed off to the guest. Handle interrupts from these > devices and route them to the appropriate guest irq lines. > The userspace provides us with the necessary information > via the ioctls. > > The guest IRQ numbers can change dynamically, so we have an > additional ioctl that keeps track of those changes in userspace > and notifies us whenever that happens. > > It is expected the kernel driver for the passthrough device > is removed before passing it on to the guest. > > > +/* > + * Used to find a registered host PCI device (a "passthrough" device) > + * during interrupts or EOI > + */ > +static struct kvm_pci_pt_dev_list * > +find_pci_pt_dev(struct list_head *head, > + struct kvm_pci_pt_info *pv_pci_info, int irq, int source) > +{ > + struct list_head *ptr; > + struct kvm_pci_pt_dev_list *match; > + > + list_for_each(ptr, head) { > + match = list_entry(ptr, struct kvm_pci_pt_dev_list, list); > + > + switch (source) { > + case KVM_PT_SOURCE_IRQ: > + /* > + * Used to find a registered host device > + * during interrupt context on host > + */ > + if (match->pt_dev.host.irq == irq) > + return match; > + break; > + case KVM_PT_SOURCE_IRQ_ACK: > + /* > + * Used to find a registered host device when > + * the guest acks an interrupt > + */ > + if (match->pt_dev.guest.irq == irq) > + return match; > + break; > + } > + } > + return NULL; > +} > This would be better as two separate functions. Also, locking? > + > +static DECLARE_BITMAP(pt_irq_pending, NR_IRQS); > +static DECLARE_BITMAP(pt_irq_handled, NR_IRQS); > + > +/* FIXME: Implement the OR logic needed to make shared interrupts on > + * this line behave properly > + */ > +static irqreturn_t > +kvm_pci_pt_dev_intr(int irq, void *dev_id) > Please don't split declarations unnecessarily. > +{ > + struct kvm_pci_pt_dev_list *match; > + struct kvm *kvm = (struct kvm *) dev_id; > + > + if (!test_bit(irq, pt_irq_handled)) > + return IRQ_NONE; > + > + if (test_bit(irq, pt_irq_pending)) > + return IRQ_HANDLED; > Will the interrupt not fire immediately after this returns? > + > + match = find_pci_pt_dev(&kvm->arch.pci_pt_dev_head, NULL, > + irq, KVM_PT_SOURCE_IRQ); > + if (!match) > + return IRQ_NONE; > + > + /* Not possible to detect if the guest uses the PIC or the > + * IOAPIC. So set the bit in both. The guest will ignore > + * writes to the unused one. > + */ > + kvm_ioapic_set_irq(kvm->arch.vioapic, match->pt_dev.guest.irq, 1); > + kvm_pic_set_irq(pic_irqchip(kvm), match->pt_dev.guest.irq, 1); > A function that calls both the apic and the pic is better, as it will be easier to port. > + set_bit(irq, pt_irq_pending); > + return IRQ_HANDLED; > +} > + > +/* Ack the irq line for a passthrough device */ > +void > +kvm_pci_pt_ack_irq(struct kvm *kvm, int vector) > +{ > + int irq; > + struct kvm_pci_pt_dev_list *match; > + > + irq = get_eoi_gsi(kvm->arch.vioapic, vector); > + match = find_pci_pt_dev(&kvm->arch.pci_pt_dev_head, NULL, > + irq, KVM_PT_SOURCE_IRQ_ACK); > + if (!match) > + return; > + if (test_bit(match->pt_dev.host.irq, pt_irq_pending)) { > + kvm_ioapic_set_irq(kvm->arch.vioapic, irq, 0); > + kvm_pic_set_irq(pic_irqchip(kvm), irq, 0); > This is dangerous with smp guests, if we aren't careful with the ordering the interrupt may fire again and be forwarded to the other vcpu. We need to call this before we redeliver interrupts. > + clear_bit(match->pt_dev.host.irq, pt_irq_pending); > + } > +} > + > +static int > +kvm_vm_ioctl_pci_pt_dev(struct kvm *kvm, > + struct kvm_pci_passthrough_dev *pci_pt_dev) > +{ > + int r = 0; > + struct kvm_pci_pt_dev_list *match; > + > + if (irqchip_in_kernel(kvm)) { > + /* Has this been added already? */ > + if (find_pci_pt_dev(&kvm->arch.pci_pt_dev_head, > + NULL, pci_pt_dev->host.irq, > + KVM_PT_SOURCE_IRQ)) > + goto out; > + > + match = kzalloc(sizeof(struct kvm_pci_pt_dev_list), GFP_KERNEL); > + if (match == NULL) { > + printk(KERN_INFO "%s: Couldn't allocate memory\n", > + __FUNCTION__); > + r = -ENOMEM; > + goto out; > + } > + > + match->pt_dev.guest.irq = pci_pt_dev->guest.irq; > + match->pt_dev.host.irq = pci_pt_dev->host.irq; > + > + if (request_irq(pci_pt_dev->host.irq, kvm_pci_pt_dev_intr, > + IRQF_SHARED, "kvm_pv_device", (void *)kvm)) { > + printk(KERN_INFO "%s: couldn't allocate irq for pv " > + "device\n", __FUNCTION__); > + r = -EIO; > + goto out_free; > + } > + set_bit(pci_pt_dev->host.irq, pt_irq_handled); > + list_add(&match->list, &kvm->arch.pci_pt_dev_head); > + } > + out: > + return r; > + out_free: > + kfree(match); > + goto out; > +} > Locking? > @@ -1671,6 +1836,30 @@ long kvm_arch_vm_ioctl(struct file *filp, > r = 0; > break; > } > + case KVM_ASSIGN_PCI_PT_DEV: { > + struct kvm_pci_passthrough_dev pci_pt_dev; > + > + r = -EFAULT; > + if (copy_from_user(&pci_pt_dev, argp, sizeof pci_pt_dev)) > + goto out; > + > + r = kvm_vm_ioctl_pci_pt_dev(kvm, &pci_pt_dev); > + if (r) > + goto out; > + break; > + } > + case KVM_UPDATE_PCI_PT_IRQ: { > + struct kvm_pci_passthrough_dev pci_pt_dev; > + > + r = -EFAULT; > + if (copy_from_user(&pci_pt_dev, argp, sizeof pci_pt_dev)) > + goto out; > + > + r = kvm_vm_ioctl_pci_pt_irq(kvm, &pci_pt_dev); > + if (r) > + goto out; > + break; > + } > Could these not be merged? > diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h > index 781fc87..c4eb804 100644 > --- a/include/asm-x86/kvm_host.h > +++ b/include/asm-x86/kvm_host.h > @@ -296,6 +296,18 @@ struct kvm_mem_alias { > gfn_t target_gfn; > }; > > +/* Some definitions for passthrough'ed devices */ > "passthrough'ed" and especially "pt" are awkward. How about "assigned"? > +#define KVM_PT_SOURCE_IRQ 1 > +#define KVM_PT_SOURCE_IRQ_ACK 2 > + > +/* This list is to store the guest bus:device:function and host > + * bus:device:function mapping for passthrough'ed devices. > + */ > ? -- error compiling committee.c: too many arguments to function |
From: Avi K. <av...@qu...> - 2008-04-13 08:22:30
|
Amit Shah wrote: > > -static int get_eoi_gsi(struct kvm_ioapic *ioapic, int vector) > +int get_eoi_gsi(struct kvm_ioapic *ioapic, int vector) > Such a generic name should be prefixed by kvm_ if you expose it. -- error compiling committee.c: too many arguments to function |
From: 钟文辉 <she...@12...> - 2008-04-13 06:20:40
|
各位老总:您们好! 诚祝:您们在2008年里;有鼠不尽的快乐!鼠不尽的收获!鼠不尽的钞票! 鼠不尽的幸福!鼠不尽的美满生活!愿: 您们阖家欢乐!幸福安康! 我是(深圳市珊湖岛进出口有限公司)的负责人;可以提供:出口报关单, 核销单等等一系列手续;代理:出口报关,商检,境内外运输......等等;还可 以代办:出口欧盟许可证,欧盟产地证;并且还有(广州国际贸易交易会)的摊 位可以转让;有意者请来邮件或来电联系;谢谢合作! 电话:0755-81153047。 传真:0755-81172940。 手机:15817477278。 联系人:钟文辉。 此致: 敬礼! |
From: 钟文辉 <she...@12...> - 2008-04-13 05:42:28
|
各位老总:您们好! 诚祝:您们在2008年里;有鼠不尽的快乐!鼠不尽的收获!鼠不尽的钞票! 鼠不尽的幸福!鼠不尽的美满生活!愿: 您们阖家欢乐!幸福安康! 我是(深圳市珊湖岛进出口有限公司)的负责人;可以提供:出口报关单, 核销单等等一系列手续;代理:出口报关,商检,境内外运输......等等;还可 以代办:出口欧盟许可证,欧盟产地证;并且还有(广州国际贸易交易会)的摊 位可以转让;有意者请来邮件或来电联系;谢谢合作! 电话:0755-81153047。 传真:0755-81172940。 手机:15817477278。 联系人:钟文辉。 此致: 敬礼! |
From: Miek <cnr...@aa...> - 2008-04-12 15:51:19
|
Girls will go wild when they see your magnificent device http://www.pogieapie.com/ |
From: Andrea A. <an...@qu...> - 2008-04-12 12:22:59
|
On Sat, Apr 12, 2008 at 01:11:27PM +0530, Amit Shah wrote: > Well bcc, iasl on my machine have some problem. The versions I'm using are: andrea@duo ~ $ esearch iasl dev86 [ Results for search key : iasl ] [ Applications found : 1 ] * sys-power/iasl Latest version available: 20060912 Latest version installed: 20060912 Size of downloaded files: [no/bad digest] Homepage: http://www.intel.com/technology/iapc/acpi/ Description: Intel ACPI Source Language (ASL) compiler License: iASL [ Results for search key : dev86 ] [ Applications found : 1 ] * sys-devel/dev86 Latest version available: 0.16.17-r5 Latest version installed: 0.16.17-r5 Size of downloaded files: [no/bad digest] Homepage: http://www.cix.co.uk/~mayday Description: Bruce's C compiler - Simple C compiler to generate 8086 code License: GPL-2 They worked fine. > Avi: do we have a machine where we have this setup for me to compile the bios? I will send the patched bios to you by email in the meantime. |
From: Amit S. <ami...@qu...> - 2008-04-12 07:41:59
|
* On Saturday 12 Apr 2008 00:06:32 Andrea Arcangeli wrote: > On Fri, Apr 11, 2008 at 05:43:03PM +0530, Amit Shah wrote: > > Hi Andrea, > > > > Did you have to recompile the bios? How did you do that (or did you ask > > Avi to > > Yes. > > > generate it?) Do you have a binary of the bios that I can use to test > > reserved ram? > > make bios; make install should do the trick, the new bios should run > after that. Well bcc, iasl on my machine have some problem. Avi: do we have a machine where we have this setup for me to compile the bios? Amit |
From: Anthony L. <an...@co...> - 2008-04-12 00:22:46
|
Alberto Treviño wrote: > When I try to boot from a SCSI device using grub, Qemu crashes (see > below). I have been able to boot from SCSI devices using Windows, but > anytime I use grub I get a crash, even when booting off a CD with grub. > Any ideas? > > # qemu-system-x86_64 -drive \ > file=junk.raw,if=scsi,bus=0,index=0,media=disk,boot=on \ > -cdrom /srv/vm/.kvm/install/slim-cd-v4.iso -boot d \ > -m 64 -vnc :0 > You aren't booting from SCSI, you're booting from a CDROM. Does the problem still exist if you omit ,boot=on? My suspicion is that you're seeing the classic big real mode problem. What guest are you trying to install? Regards, Anthony Liguori > exception 13 (33) > rax 0000000000000000 rbx 0000000000000800 rcx 0000000000000000 rdx > 00000000000000e0 > rsi 00000000ffff7d98 rdi 000000000008f788 rsp 0000000000002018 rbp > 0000000000000001 > r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 > 0000000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 > 0000000000000000 > rip 0000000000000003 rflags 00033202 > cs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ds 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > es 0800 (00008000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ss 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > tr 0000 (fffbd000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) > gdt fb1f2/30 > idt 0/3ff > cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > code: 53 ff 00 --> f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 > ff 00 f0 53 ff 00 f0 53 ff 00 f0 a5 fe 00 f0 87 e9 00 f0 53 ff 00 f0 53 > ff 00 f0 53 ff > Aborted > > |