Amit Shah wrote: > On Thursday 19 June 2008 10:17:29 Amit Shah wrote: >> * On Wednesday 18 June 2008 18:26:16 Ben-Ami Yassour wrote: >>> Amit, >>> >>> With the current implementation we have an issue if the driver on >>> the host was never loaded. >>> >>> To be able to run kvm with passthrough we have to load and then >>> unload the driver on the host at least once. After that it works ok. >> >> Yes, whenever a device issues pci_request_regions(), the IRQ may be >> reassigned. >> >> The unloading / loading should not be necessary once I commit these >> changes to the tree. >> >>> Note that after doing the load and unload the irq as reported by >>> lspci -v is changed. >>> >>> The questions that I think we need to figure out are: >>> 1. How does the loading of the driver on the host causes the irq to >>> change? >>> 2. What other side effects does it do that helps kvm pcipt work? >>> 3. What do we need to add to the pcipt code that will do the same >>> "side effect" (or bypass the problem)? >> >> That already answers all these. >> >>> Also note that in the current implementation the user is required to >>> provide the irq for the device in the kvm command line. >>> With respect to the comments above it is clear that lspci will show >>> an irrelevant irq value. Why do we need the user to provide this >>> information anyhow? >>> Why can't KVM find it out automatically? >> >> I thought we discussed this several times. The next commit is going >> to fix this. >> >>> Note, if the kernel can find this information then we can also >>> remove it from the ioctl interface. >> >> Coming soon; coming soon indeed. > > I just pushed out the changes so the trickery with module loading / > unloading, assigning irq number, etc. are not needed. The userspace > command line still expects a number for the irq, though, and you can > pass it any number as long as you use the in-kernel irq handler > (this is needed for the irqhook module, which I'm not updating the > irqhook module as of now). >
Amit, it doesn't work with VT-d even passing correct IRQ. The output is as follows: irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.26-rc3-00988-g6d9586a-dirty #5 Call Trace: <IRQ> [<ffffffff802538eb>] __report_bad_irq+0x30/0x72 [<ffffffff80253b23>] note_interrupt+0x1f6/0x233 [<ffffffff802543ab>] handle_fasteoi_irq+0xa5/0xc8 [<ffffffff8020db0b>] do_IRQ+0xf1/0x162 [<ffffffff8020b581>] ret_from_intr+0x0/0xa <EOI> [<ffffffff8038ad82>] acpi_idle_enter_simple+0x180/0x1ea [<ffffffff8038ad78>] acpi_idle_enter_simple+0x176/0x1ea [<ffffffff8049f195>] cpuidle_idle_call+0x73/0xaa [<ffffffff8049f122>] cpuidle_idle_call+0x0/0xaa [<ffffffff80209e6b>] cpu_idle+0x6d/0x8b handlers: [<ffffffff8046a083>] (usb_hcd_irq+0x0/0x51) [<ffffffff8046a083>] (usb_hcd_irq+0x0/0x51) Disabling IRQ #16 But I found kvm_vm_ioctl_pci_pt_dev() indeed got the correct IRQ for the assigned device before request_irq(). Randy (Weidong) > A couple of notes for the VT-d patch: > - The pci_dev struct is now available in the pci_pt kernel structure, > so just use that information each time you want to add a device > instead of searching for it each time. > - The kernel with KVM VT-d patches doesn't build on the > kvm-userspace.git tree. Please fix that. > > Amit. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
