Re: PCI PT: irq issue
On Wednesday 25 June 2008 15:03:11 Han, Weidong wrote: > Amit Shah wrote: > > On Monday 23 June 2008 20:46:18 Han, Weidong wrote: > >> Amit Shah wrote: > >>> On Saturday 21 June 2008 09:41:18 Han, Weidong wrote: > Amit Shah wrote: > > 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. > > I pulled the latest VT-d branch, and it works fine for me. > >>> > >>> I mean the 'vtd' branch in the kernel tree with 'master' branch of > >>> the userspace tree aren't compatible. > > Amit, why do you want them to be compatible? 'vtd' branch of the kernel > tree and 'vtd' branch of the userspace tree is the combination. right? > 'master' branch of the userspace may don't have some patches which in > 'vtd' branch of the userspace. We need this for compatibility: old kernel with new userspace and new kernel with old userspace should all work fine. 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
RE: PCI PT: irq issue
Amit Shah wrote: > On Monday 23 June 2008 20:46:18 Han, Weidong wrote: >> Amit Shah wrote: >>> On Saturday 21 June 2008 09:41:18 Han, Weidong wrote: Amit Shah wrote: > 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. I pulled the latest VT-d branch, and it works fine for me. >>> >>> I mean the 'vtd' branch in the kernel tree with 'master' branch of >>> the userspace tree aren't compatible. Amit, why do you want them to be compatible? 'vtd' branch of the kernel tree and 'vtd' branch of the userspace tree is the combination. right? 'master' branch of the userspace may don't have some patches which in 'vtd' branch of the userspace. Randy (Weidong) >> >> I tried it. It can build. Can you show me the errors? > > If you compile kvm as external modules, the userspace tree doesn't > contain the vtd.o file while linking, but kvm.ko refers to objects > within it: > > > Building modules, stage 2. > MODPOST 3 modules > WARNING: "kvm_intel_iommu_found" > [/home/amit/src/kvm-userspace/kernel/kvm.ko] undefined! > WARNING: "kvm_iommu_unmap_guest" > [/home/amit/src/kvm-userspace/kernel/kvm.ko] undefined! > WARNING: "kvm_iommu_map_guest" > [/home/amit/src/kvm-userspace/kernel/kvm.ko] undefined! > WARNING: "kvm_iommu_map_pages" > [/home/amit/src/kvm-userspace/kernel/kvm.ko] undefined! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCI PT: irq issue
On Monday 23 June 2008 20:46:18 Han, Weidong wrote: > Amit Shah wrote: > > On Saturday 21 June 2008 09:41:18 Han, Weidong wrote: > >> Amit Shah wrote: > >>> 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. > >> > >> I pulled the latest VT-d branch, and it works fine for me. > > > > I mean the 'vtd' branch in the kernel tree with 'master' branch of the > > userspace tree aren't compatible. > > I tried it. It can build. Can you show me the errors? If you compile kvm as external modules, the userspace tree doesn't contain the vtd.o file while linking, but kvm.ko refers to objects within it: Building modules, stage 2. MODPOST 3 modules WARNING: "kvm_intel_iommu_found" [/home/amit/src/kvm-userspace/kernel/kvm.ko] undefined! WARNING: "kvm_iommu_unmap_guest" [/home/amit/src/kvm-userspace/kernel/kvm.ko] undefined! WARNING: "kvm_iommu_map_guest" [/home/amit/src/kvm-userspace/kernel/kvm.ko] undefined! WARNING: "kvm_iommu_map_pages" [/home/amit/src/kvm-userspace/kernel/kvm.ko] undefined! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: PCI PT: irq issue
Amit Shah wrote: > On Saturday 21 June 2008 09:41:18 Han, Weidong wrote: >> Amit Shah wrote: > >>> 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. >> >> I pulled the latest VT-d branch, and it works fine for me. > > I mean the 'vtd' branch in the kernel tree with 'master' branch of the > userspace tree aren't compatible. I tried it. It can build. Can you show me the errors? Randy (Weidong) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCI PT: irq issue
On Saturday 21 June 2008 09:41:18 Han, Weidong wrote: > Amit Shah wrote: > > 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. > > I pulled the latest VT-d branch, and it works fine for me. I mean the 'vtd' branch in the kernel tree with 'master' branch of the userspace tree aren't compatible. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCI PT: irq issue
On Monday 23 June 2008 11:34:43 Han, Weidong wrote: > Amit Shah wrote: > 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: > [] __report_bad_irq+0x30/0x72 > [] note_interrupt+0x1f6/0x233 > [] handle_fasteoi_irq+0xa5/0xc8 > [] do_IRQ+0xf1/0x162 > [] ret_from_intr+0x0/0xa > [] acpi_idle_enter_simple+0x180/0x1ea > [] acpi_idle_enter_simple+0x176/0x1ea > [] cpuidle_idle_call+0x73/0xaa > [] cpuidle_idle_call+0x0/0xaa > [] cpu_idle+0x6d/0x8b > > handlers: > [] (usb_hcd_irq+0x0/0x51) > [] (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(). My mistake; I forgot to push the fix. Updated the tree now. 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
RE: PCI PT: irq issue
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: [] __report_bad_irq+0x30/0x72 [] note_interrupt+0x1f6/0x233 [] handle_fasteoi_irq+0xa5/0xc8 [] do_IRQ+0xf1/0x162 [] ret_from_intr+0x0/0xa [] acpi_idle_enter_simple+0x180/0x1ea [] acpi_idle_enter_simple+0x176/0x1ea [] cpuidle_idle_call+0x73/0xaa [] cpuidle_idle_call+0x0/0xaa [] cpu_idle+0x6d/0x8b handlers: [] (usb_hcd_irq+0x0/0x51) [] (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
RE: PCI PT: irq issue
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). > > 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. > I pulled the latest VT-d branch, and it works fine for me. Randy (Weidong) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCI PT: irq issue
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). 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
Re: PCI PT: irq issue
* 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. -- 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
PCI PT: irq issue
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. 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)? 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? Note, if the kernel can find this information then we can also remove it from the ioctl interface. Thanks, Ben -- 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
