RE: PCI PT: irq issue

2008-06-25 Thread Han, Weidong
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

2008-06-25 Thread Amit Shah
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

2008-06-24 Thread Amit Shah
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

2008-06-23 Thread Han, Weidong
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  [802538eb] __report_bad_irq+0x30/0x72
  [80253b23] note_interrupt+0x1f6/0x233
  [802543ab] handle_fasteoi_irq+0xa5/0xc8
  [8020db0b] do_IRQ+0xf1/0x162
  [8020b581] ret_from_intr+0x0/0xa
  EOI  [8038ad82] acpi_idle_enter_simple+0x180/0x1ea
  [8038ad78] acpi_idle_enter_simple+0x176/0x1ea
  [8049f195] cpuidle_idle_call+0x73/0xaa
  [8049f122] cpuidle_idle_call+0x0/0xaa
  [80209e6b] cpu_idle+0x6d/0x8b
 
 handlers:
 [8046a083] (usb_hcd_irq+0x0/0x51)
 [8046a083] (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

2008-06-23 Thread Amit Shah
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:
   IRQ  [802538eb] __report_bad_irq+0x30/0x72
   [80253b23] note_interrupt+0x1f6/0x233
   [802543ab] handle_fasteoi_irq+0xa5/0xc8
   [8020db0b] do_IRQ+0xf1/0x162
   [8020b581] ret_from_intr+0x0/0xa
   EOI  [8038ad82] acpi_idle_enter_simple+0x180/0x1ea
   [8038ad78] acpi_idle_enter_simple+0x176/0x1ea
   [8049f195] cpuidle_idle_call+0x73/0xaa
   [8049f122] cpuidle_idle_call+0x0/0xaa
   [80209e6b] cpu_idle+0x6d/0x8b

  handlers:
  [8046a083] (usb_hcd_irq+0x0/0x51)
  [8046a083] (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

2008-06-23 Thread Amit Shah
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

2008-06-23 Thread Han, Weidong
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

2008-06-20 Thread Han, Weidong
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


PCI PT: irq issue

2008-06-18 Thread Ben-Ami Yassour
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