Kay, Allen M
2007-Sep-05 00:08 UTC
[Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
The following 6 patches contains merge of Intel VT-d and Neocleus'' 1:1 mapping patches for enabling HVM guest direct device access that were last submitted around end of May. These patches applied cleanly to changeset 15730. To enabled xen vt-d code, add "ioapic_ack=old" to xen boot parameter in grub.conf on systems with VT-d hardware. To enabled xen 1:1 mapping code, add "enabled_nativedom=1" to xen boot parameter in grub.conf. Signed-off-by: Allen Kay <allen.m.kay@intel.com> Signed-off-by: Guy Zana <guy@neocleus.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
John Byrne
2007-Sep-06 23:16 UTC
Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
When I use these patches and start a nativedom with a directly-assigned NIC and no IOMMU, I get a lock up. Running the same domain/configuration/machine with the direct-io.hg tree worked fine. The crash output is below. If you''d like more information, let me know. John Byrne (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) WARNING: send pio with something already pending (9)? (XEN) domain_crash_sync called from hvm.c:485 (XEN) Domain 1 (vcpu#0) crashed on cpu#7: (XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]---- (XEN) CPU: 7 (XEN) EIP: 0000:[<00100fcb>] (XEN) EFLAGS: 00000002 CONTEXT: hvm (XEN) eax: 00000064 ebx: 001390c4 ecx: 001390c4 edx: 000000e9 (XEN) esi: 00103762 edi: 00101bf0 ebp: 00139038 esp: 00139038 (XEN) cr0: 00000011 cr4: 00000000 cr3: 00000000 cr2: 00000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) domain_crash_sync called from hvm.c:132 (XEN) domain_crash_sync called from hvm.c:132 (XEN) domain_crash_sync called from hvm.c:132 (XEN) domain_crash_sync called from hvm.c:132 .... (XEN) *** [ Xen-3.0-unstable x86_32 debug=n Not tainted ]----(XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]----(XEN) e x86_32 debug=n Not tainted ]---- (XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]---- (XEN) CPU: 6 (XEN) CPU: 6(XEN) idle_loop+0x1b/0x90+010246 CONTEXT: hypervisor (XEN) EFLAGS: 00010246 CONTEXT: hypervisor (XEN) eax: 00000300 ebx: ffbe7fb4 ecx: 00000000 edx: 00000006 (XEN) esi: ff1a8430 edi: 91d91b27 ebp: 0000001c esp: ffbe7fa8 (XEN) cr0: 8005003b cr4: 000026d0 cr3: 3c6ee000 cr2: b7bf7000 (XEN) ds: e010 es: e010 fs: 0000 gs: 0000 ss: e010 cs: e008 (XEN) do_page_fault+0x45/0x3b0 (XEN) (XEN) Xen stac00010246Xen stac00010246 CR3: 00000000(XEN) ffbea080 ax: 6563696c ebx: 0000e010 ecx: 00010246 edx: ff1b7fb4(XEN) ffbea080 00000001 si: 0000e010 edi: 00000000 ebp: ff1b40ec esp: ff1b40a8(XEN) 00000000 s: e010 es: e010 fs: 0000 gs: 0000 ss: e010(XEN) c1351f90 00000006 00000006 00000006 (XEN) c03d7180 00000000 000e0007 c01013a7 00000061 00000246 c1351f8c 00000069 (XEN) 0000007b 0000007b 00000000 00000000 00000006 ffbea080 (XEN) Xen call trace: (XEN) [<ff1209fb>] idle_loop+0x1b/0x90 (XEN) Kay, Allen M wrote:> The following 6 patches contains merge of Intel VT-d and Neocleus'' 1:1 > mapping patches for enabling HVM guest direct device access that were > last submitted around end of May. These patches applied cleanly to > changeset 15730. > > To enabled xen vt-d code, add "ioapic_ack=old" to xen boot parameter in > grub.conf on systems with VT-d hardware. > > To enabled xen 1:1 mapping code, add "enabled_nativedom=1" to xen boot > parameter in grub.conf. > > Signed-off-by: Allen Kay <allen.m.kay@intel.com> > Signed-off-by: Guy Zana <guy@neocleus.com> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2007-Sep-07 00:00 UTC
RE: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
Other than minor changes while rebasing from 15521 to 15730. The following files have been modified that might affect functionality: Tools/hvmloader/32bitbios_support.c: removed a hack to increase highbiosarea size. Tools/ioemu/hw/pass-throught.c/pt_pci_write_config(): for is_native=1 case, pass-through pci config writes. Otherwise, pass-through only access to command register (for vt-d case). Note that we will use a different switch variable once it is added. These are minor changes, you might want to replace these file from the ones from direct-io tree to see if it fixes your problem. Allen>-----Original Message----- >From: John Byrne [mailto:john.l.byrne@hp.com] >Sent: Thursday, September 06, 2007 4:16 PM >To: Kay, Allen M >Cc: xen-devel@lists.xensource.com; Guy Zana; Keir Fraser >Subject: Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel >VT-d/Neocleus 1:1 mreged code for PCI passthrough > >When I use these patches and start a nativedom with a >directly-assigned >NIC and no IOMMU, I get a lock up. Running the same >domain/configuration/machine with the direct-io.hg tree worked >fine. The >crash output is below. If you''d like more information, let me know. > >John Byrne > >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) WARNING: send pio with something already pending (9)? >(XEN) domain_crash_sync called from hvm.c:485 >(XEN) Domain 1 (vcpu#0) crashed on cpu#7: >(XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]---- >(XEN) CPU: 7 >(XEN) EIP: 0000:[<00100fcb>] >(XEN) EFLAGS: 00000002 CONTEXT: hvm >(XEN) eax: 00000064 ebx: 001390c4 ecx: 001390c4 edx: 000000e9 >(XEN) esi: 00103762 edi: 00101bf0 ebp: 00139038 esp: 00139038 >(XEN) cr0: 00000011 cr4: 00000000 cr3: 00000000 cr2: 00000000 >(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 >(XEN) domain_crash_sync called from hvm.c:132 >(XEN) domain_crash_sync called from hvm.c:132 >(XEN) domain_crash_sync called from hvm.c:132 >(XEN) domain_crash_sync called from hvm.c:132 >.... >(XEN) *** [ Xen-3.0-unstable x86_32 debug=n Not tainted ]----(XEN) >----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]----(XEN) e >x86_32 debug=n Not tainted ]---- >(XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]---- >(XEN) CPU: 6 >(XEN) CPU: 6(XEN) idle_loop+0x1b/0x90+010246 CONTEXT: hypervisor > >(XEN) EFLAGS: 00010246 CONTEXT: hypervisor >(XEN) eax: 00000300 ebx: ffbe7fb4 ecx: 00000000 edx: 00000006 >(XEN) esi: ff1a8430 edi: 91d91b27 ebp: 0000001c esp: ffbe7fa8 >(XEN) cr0: 8005003b cr4: 000026d0 cr3: 3c6ee000 cr2: b7bf7000 >(XEN) ds: e010 es: e010 fs: 0000 gs: 0000 ss: e010 cs: e008 >(XEN) do_page_fault+0x45/0x3b0 >(XEN) (XEN) Xen stac00010246Xen stac00010246 >CR3: 00000000(XEN) ffbea080 > ax: 6563696c ebx: 0000e010 ecx: 00010246 edx: ff1b7fb4(XEN) >ffbea080 00000001 > si: 0000e010 edi: 00000000 ebp: ff1b40ec esp: ff1b40a8(XEN) >00000000 > s: e010 es: e010 fs: 0000 gs: 0000 ss: e010(XEN) c1351f90 >00000006 00000006 > 00000006 >(XEN) c03d7180 00000000 000e0007 c01013a7 00000061 00000246 >c1351f8c >00000069 >(XEN) 0000007b 0000007b 00000000 00000000 00000006 ffbea080 >(XEN) Xen call trace: >(XEN) [<ff1209fb>] idle_loop+0x1b/0x90 >(XEN) > > >Kay, Allen M wrote: >> The following 6 patches contains merge of Intel VT-d and >Neocleus'' 1:1 >> mapping patches for enabling HVM guest direct device access that were >> last submitted around end of May. These patches applied cleanly to >> changeset 15730. >> >> To enabled xen vt-d code, add "ioapic_ack=old" to xen boot >parameter in >> grub.conf on systems with VT-d hardware. >> >> To enabled xen 1:1 mapping code, add "enabled_nativedom=1" >to xen boot >> parameter in grub.conf. >> >> Signed-off-by: Allen Kay <allen.m.kay@intel.com> >> Signed-off-by: Guy Zana <guy@neocleus.com> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
John Byrne
2007-Sep-07 23:44 UTC
Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
I replaced the files. The problem still occurs. John Kay, Allen M wrote:> Other than minor changes while rebasing from 15521 to 15730. The > following files have been modified that might affect functionality: > > Tools/hvmloader/32bitbios_support.c: > removed a hack to increase highbiosarea size. > > Tools/ioemu/hw/pass-throught.c/pt_pci_write_config(): > for is_native=1 case, pass-through pci config writes. Otherwise, > pass-through only access to command register (for vt-d case). Note that > we will use a different switch variable once it is added. > > These are minor changes, you might want to replace these file from the > ones from direct-io tree to see if it fixes your problem. > > Allen > > >> -----Original Message----- >> From: John Byrne [mailto:john.l.byrne@hp.com] >> Sent: Thursday, September 06, 2007 4:16 PM >> To: Kay, Allen M >> Cc: xen-devel@lists.xensource.com; Guy Zana; Keir Fraser >> Subject: Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel >> VT-d/Neocleus 1:1 mreged code for PCI passthrough >> >> When I use these patches and start a nativedom with a >> directly-assigned >> NIC and no IOMMU, I get a lock up. Running the same >> domain/configuration/machine with the direct-io.hg tree worked >> fine. The >> crash output is below. If you''d like more information, let me know. >> >> John Byrne >> >> (XEN) pt_irq.c:81:d1 invalid assert_option value >> (XEN) pt_irq.c:81:d1 invalid assert_option value >> (XEN) pt_irq.c:81:d1 invalid assert_option value >> (XEN) pt_irq.c:81:d1 invalid assert_option value >> (XEN) pt_irq.c:81:d1 invalid assert_option value >> (XEN) pt_irq.c:81:d1 invalid assert_option value >> (XEN) pt_irq.c:81:d1 invalid assert_option value >> (XEN) pt_irq.c:81:d1 invalid assert_option value >> (XEN) pt_irq.c:81:d1 invalid assert_option value >> (XEN) pt_irq.c:81:d1 invalid assert_option value >> (XEN) WARNING: send pio with something already pending (9)? >> (XEN) domain_crash_sync called from hvm.c:485 >> (XEN) Domain 1 (vcpu#0) crashed on cpu#7: >> (XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]---- >> (XEN) CPU: 7 >> (XEN) EIP: 0000:[<00100fcb>] >> (XEN) EFLAGS: 00000002 CONTEXT: hvm >> (XEN) eax: 00000064 ebx: 001390c4 ecx: 001390c4 edx: 000000e9 >> (XEN) esi: 00103762 edi: 00101bf0 ebp: 00139038 esp: 00139038 >> (XEN) cr0: 00000011 cr4: 00000000 cr3: 00000000 cr2: 00000000 >> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 >> (XEN) domain_crash_sync called from hvm.c:132 >> (XEN) domain_crash_sync called from hvm.c:132 >> (XEN) domain_crash_sync called from hvm.c:132 >> (XEN) domain_crash_sync called from hvm.c:132 >> .... >> (XEN) *** [ Xen-3.0-unstable x86_32 debug=n Not tainted ]----(XEN) >> ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]----(XEN) e >> x86_32 debug=n Not tainted ]---- >> (XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]---- >> (XEN) CPU: 6 >> (XEN) CPU: 6(XEN) idle_loop+0x1b/0x90+010246 CONTEXT: hypervisor >> >> (XEN) EFLAGS: 00010246 CONTEXT: hypervisor >> (XEN) eax: 00000300 ebx: ffbe7fb4 ecx: 00000000 edx: 00000006 >> (XEN) esi: ff1a8430 edi: 91d91b27 ebp: 0000001c esp: ffbe7fa8 >> (XEN) cr0: 8005003b cr4: 000026d0 cr3: 3c6ee000 cr2: b7bf7000 >> (XEN) ds: e010 es: e010 fs: 0000 gs: 0000 ss: e010 cs: e008 >> (XEN) do_page_fault+0x45/0x3b0 >> (XEN) (XEN) Xen stac00010246Xen stac00010246 >> CR3: 00000000(XEN) ffbea080 >> ax: 6563696c ebx: 0000e010 ecx: 00010246 edx: ff1b7fb4(XEN) >> ffbea080 00000001 >> si: 0000e010 edi: 00000000 ebp: ff1b40ec esp: ff1b40a8(XEN) >> 00000000 >> s: e010 es: e010 fs: 0000 gs: 0000 ss: e010(XEN) c1351f90 >> 00000006 00000006 >> 00000006 >> (XEN) c03d7180 00000000 000e0007 c01013a7 00000061 00000246 >> c1351f8c >> 00000069 >> (XEN) 0000007b 0000007b 00000000 00000000 00000006 ffbea080 >> (XEN) Xen call trace: >> (XEN) [<ff1209fb>] idle_loop+0x1b/0x90 >> (XEN) >> >> >> Kay, Allen M wrote: >>> The following 6 patches contains merge of Intel VT-d and >> Neocleus'' 1:1 >>> mapping patches for enabling HVM guest direct device access that were >>> last submitted around end of May. These patches applied cleanly to >>> changeset 15730. >>> >>> To enabled xen vt-d code, add "ioapic_ack=old" to xen boot >> parameter in >>> grub.conf on systems with VT-d hardware. >>> >>> To enabled xen 1:1 mapping code, add "enabled_nativedom=1" >> to xen boot >>> parameter in grub.conf. >>> >>> Signed-off-by: Allen Kay <allen.m.kay@intel.com> >>> Signed-off-by: Guy Zana <guy@neocleus.com> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >>> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Sep-11 12:49 UTC
Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
On 5/9/07 01:08, "Kay, Allen M" <allen.m.kay@intel.com> wrote:> The following 6 patches contains merge of Intel VT-d and Neocleus'' 1:1 > mapping patches for enabling HVM guest direct device access that were > last submitted around end of May. These patches applied cleanly to > changeset 15730.The ''include'' patch doesn''t apply any more, and in any case needs splitting up logically (vtd bits go in vtd patch; neo bits in neo patch; any generic bits in xen patch). The ''pt'' (neo) code looks to throw way too much stuff in include/xen/ of which I suspect most is private definitions that really belong in the pt/ directory. Also consider which bits should be in include/asm rather than include/xen. The presence of the E820_1TO1 stuff makes me suspect that the 1:1 area allocation hasn''t been cleaned up as much as it should have been. There shouldn''t be any need to modify Xen''s permanent e820 map I think. Haven''t looked any further at the Xen parts, but I''ll take a look at the tools patch... -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Sep-11 13:04 UTC
Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
On 11/9/07 13:49, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote:> Haven''t looked any further at the Xen parts, but I''ll take a look at the > tools patch...Looking at the tools patch, I see strange interfaces like HVMOP_copy_nativedom_e820_map: 1. Why is this an hvm_op unlike other added domctls? 2. Why is it needed at all? Can''t xc_hvm_build.c work out the memory map for itself? It seems like more than necessary is being done in Xen. Looks like splitting solely pt and solely vtd code into separate patches would be a good idea, so the more acdeptable chunks can slide straight in without delay. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2007-Sep-11 21:27 UTC
RE: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
Attached are header file patches I rebased to cs# 15837. I moved neo''s include file from xen to xen/asm. I couldn''t move them to xen/arch/x86/pt directory because some generic file reference them. Vtd_inc.patch: include generic changes and one vt-d file (intel-iommu.h) P2m_inc.patch: changes to p2m.h Neo_inc.patch: Neocleus specific changes Signed-off-by: Allen Kay <allen.m.kay@intel.com> Signed-off-by: Guy Zana <guy@neocleus.com> Allen>-----Original Message----- >From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: Tuesday, September 11, 2007 5:50 AM >To: Kay, Allen M; xen-devel@lists.xensource.com >Cc: Guy Zana >Subject: Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel >VT-d/Neocleus 1:1 mreged code for PCI passthrough > >On 5/9/07 01:08, "Kay, Allen M" <allen.m.kay@intel.com> wrote: > >> The following 6 patches contains merge of Intel VT-d and >Neocleus'' 1:1 >> mapping patches for enabling HVM guest direct device access that were >> last submitted around end of May. These patches applied cleanly to >> changeset 15730. > >The ''include'' patch doesn''t apply any more, and in any case >needs splitting >up logically (vtd bits go in vtd patch; neo bits in neo patch; >any generic >bits in xen patch). The ''pt'' (neo) code looks to throw way too >much stuff in >include/xen/ of which I suspect most is private definitions that really >belong in the pt/ directory. Also consider which bits should be in >include/asm rather than include/xen. > >The presence of the E820_1TO1 stuff makes me suspect that the 1:1 area >allocation hasn''t been cleaned up as much as it should have been. There >shouldn''t be any need to modify Xen''s permanent e820 map I think. > >Haven''t looked any further at the Xen parts, but I''ll take a >look at the >tools patch... > > -- Keir >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2007-Sep-12 01:21 UTC
RE: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
Attached patches splits vtd and neo changes to tools directory. Applies cleanly to staging tree. Vtd_tools.patch: vt-d and generic changes Neo_tools.patch: neocleus specific changes Signed-off-by: Allen Kay <allen.m.kay@intel.com> Signed-off-by: Guy Zana <guy@neocleus.com>>-----Original Message----- >From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: Tuesday, September 11, 2007 6:05 AM >To: Kay, Allen M; xen-devel@lists.xensource.com >Cc: Guy Zana >Subject: Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel >VT-d/Neocleus 1:1 mreged code for PCI passthrough > >On 11/9/07 13:49, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote: > >> Haven''t looked any further at the Xen parts, but I''ll take a >look at the >> tools patch... > >Looking at the tools patch, I see strange interfaces like >HVMOP_copy_nativedom_e820_map: > 1. Why is this an hvm_op unlike other added domctls? > 2. Why is it needed at all? Can''t xc_hvm_build.c work out the >memory map >for itself? It seems like more than necessary is being done in Xen. > >Looks like splitting solely pt and solely vtd code into >separate patches >would be a good idea, so the more acdeptable chunks can slide >straight in >without delay. > > -- Keir >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Sep-12 09:01 UTC
Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
Vtd_inc is applied. p2m_inc does not apply. Neo_inc not taken at this time for reasons stated in previous emails. -- Keir On 11/9/07 22:27, "Kay, Allen M" <allen.m.kay@intel.com> wrote:> Attached are header file patches I rebased to cs# 15837. I moved neo''s > include file from xen to xen/asm. I couldn''t move them to > xen/arch/x86/pt directory because some generic file reference them. > > Vtd_inc.patch: include generic changes and one vt-d file > (intel-iommu.h) > P2m_inc.patch: changes to p2m.h > Neo_inc.patch: Neocleus specific changes > > Signed-off-by: Allen Kay <allen.m.kay@intel.com> > Signed-off-by: Guy Zana <guy@neocleus.com> > > Allen > >> -----Original Message----- >> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >> Sent: Tuesday, September 11, 2007 5:50 AM >> To: Kay, Allen M; xen-devel@lists.xensource.com >> Cc: Guy Zana >> Subject: Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel >> VT-d/Neocleus 1:1 mreged code for PCI passthrough >> >> On 5/9/07 01:08, "Kay, Allen M" <allen.m.kay@intel.com> wrote: >> >>> The following 6 patches contains merge of Intel VT-d and >> Neocleus'' 1:1 >>> mapping patches for enabling HVM guest direct device access that were >>> last submitted around end of May. These patches applied cleanly to >>> changeset 15730. >> >> The ''include'' patch doesn''t apply any more, and in any case >> needs splitting >> up logically (vtd bits go in vtd patch; neo bits in neo patch; >> any generic >> bits in xen patch). The ''pt'' (neo) code looks to throw way too >> much stuff in >> include/xen/ of which I suspect most is private definitions that really >> belong in the pt/ directory. Also consider which bits should be in >> include/asm rather than include/xen. >> >> The presence of the E820_1TO1 stuff makes me suspect that the 1:1 area >> allocation hasn''t been cleaned up as much as it should have been. There >> shouldn''t be any need to modify Xen''s permanent e820 map I think. >> >> Haven''t looked any further at the Xen parts, but I''ll take a >> look at the >> tools patch... >> >> -- Keir >>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Sep-12 09:03 UTC
Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
Vtd_tools patch breaks the build on my box. Cannot find pci/header.h or pci/pci.h. Probably because libpci is not such a standard install component after all? I''m trying to build on Debian 3.1. Either the dependency needs to be avoided, or we need to be sure that the dependency is easy to resolve on most distros, and we need a tools/check script to check for and warn/error on the dependency. -- Keir On 12/9/07 02:21, "Kay, Allen M" <allen.m.kay@intel.com> wrote:> Attached patches splits vtd and neo changes to tools directory. Applies > cleanly to staging tree. > > Vtd_tools.patch: vt-d and generic changes > Neo_tools.patch: neocleus specific changes > > Signed-off-by: Allen Kay <allen.m.kay@intel.com> > Signed-off-by: Guy Zana <guy@neocleus.com> > >> -----Original Message----- >> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >> Sent: Tuesday, September 11, 2007 6:05 AM >> To: Kay, Allen M; xen-devel@lists.xensource.com >> Cc: Guy Zana >> Subject: Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel >> VT-d/Neocleus 1:1 mreged code for PCI passthrough >> >> On 11/9/07 13:49, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote: >> >>> Haven''t looked any further at the Xen parts, but I''ll take a >> look at the >>> tools patch... >> >> Looking at the tools patch, I see strange interfaces like >> HVMOP_copy_nativedom_e820_map: >> 1. Why is this an hvm_op unlike other added domctls? >> 2. Why is it needed at all? Can''t xc_hvm_build.c work out the >> memory map >> for itself? It seems like more than necessary is being done in Xen. >> >> Looks like splitting solely pt and solely vtd code into >> separate patches >> would be a good idea, so the more acdeptable chunks can slide >> straight in >> without delay. >> >> -- Keir >>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2007-Sep-12 22:37 UTC
RE: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
I have added CONFIG_PASSTHROUGH in ioemu/Makefile.target and ioemu/hw/pc.c in attached vtd_tools2.patch. This should turn off libpci usage by default until user specifically enables it. This can be safely check-in without breaking builds for people who do not care about pass-through devices. I will try to think of a better way to enable this. Also, can you check-in vtd_dir.patch if you don''t have any objections? This is a separate vt-d specific directory in hvm/vmx/vtd. It should not interfere with anything else. I''m current working on getting xen.patch part to work with latest staging tree. I will send it in as soon as I get it working. Allen Signed-off-by: Allen Kay <allen.m.kay@intel.com> Signed-off-by: Guy Zana <guy@neocleus.com>>-----Original Message----- >From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: Wednesday, September 12, 2007 2:04 AM >To: Kay, Allen M; xen-devel@lists.xensource.com >Cc: Guy Zana >Subject: Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel >VT-d/Neocleus 1:1 mreged code for PCI passthrough > >Vtd_tools patch breaks the build on my box. Cannot find pci/header.h or >pci/pci.h. Probably because libpci is not such a standard >install component >after all? I''m trying to build on Debian 3.1. > >Either the dependency needs to be avoided, or we need to be >sure that the >dependency is easy to resolve on most distros, and we need a >tools/check >script to check for and warn/error on the dependency. > > -- Keir > >On 12/9/07 02:21, "Kay, Allen M" <allen.m.kay@intel.com> wrote: > >> Attached patches splits vtd and neo changes to tools >directory. Applies >> cleanly to staging tree. >> >> Vtd_tools.patch: vt-d and generic changes >> Neo_tools.patch: neocleus specific changes >> >> Signed-off-by: Allen Kay <allen.m.kay@intel.com> >> Signed-off-by: Guy Zana <guy@neocleus.com> >> >>> -----Original Message----- >>> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >>> Sent: Tuesday, September 11, 2007 6:05 AM >>> To: Kay, Allen M; xen-devel@lists.xensource.com >>> Cc: Guy Zana >>> Subject: Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel >>> VT-d/Neocleus 1:1 mreged code for PCI passthrough >>> >>> On 11/9/07 13:49, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote: >>> >>>> Haven''t looked any further at the Xen parts, but I''ll take a >>> look at the >>>> tools patch... >>> >>> Looking at the tools patch, I see strange interfaces like >>> HVMOP_copy_nativedom_e820_map: >>> 1. Why is this an hvm_op unlike other added domctls? >>> 2. Why is it needed at all? Can''t xc_hvm_build.c work out the >>> memory map >>> for itself? It seems like more than necessary is being done in Xen. >>> >>> Looks like splitting solely pt and solely vtd code into >>> separate patches >>> would be a good idea, so the more acdeptable chunks can slide >>> straight in >>> without delay. >>> >>> -- Keir >>> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Guy Zana
2007-Sep-16 17:26 UTC
RE: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mregedcode for PCI passthrough
That will be "enable_nativedom=1" (without the ''d''). Thanks, Guy.> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Kay, Allen M > Sent: Wednesday, September 05, 2007 3:09 AM > To: xen-devel@lists.xensource.com > Cc: Guy Zana; Keir Fraser > Subject: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus > 1:1 mregedcode for PCI passthrough > > The following 6 patches contains merge of Intel VT-d and > Neocleus'' 1:1 mapping patches for enabling HVM guest direct > device access that were last submitted around end of May. > These patches applied cleanly to changeset 15730. > > To enabled xen vt-d code, add "ioapic_ack=old" to xen boot > parameter in grub.conf on systems with VT-d hardware. > > To enabled xen 1:1 mapping code, add "enabled_nativedom=1" to > xen boot parameter in grub.conf. > > Signed-off-by: Allen Kay <allen.m.kay@intel.com> > Signed-off-by: Guy Zana <guy@neocleus.com> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Sep-17 08:25 UTC
Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mregedcode for PCI passthrough
Better to use a boolean param called ''nativedom''. Then the user can automatically specify any one of ''nativedom'', ''nativedom=on'', ''nativedom=1'', ''nativedom=true'', ... -- Keir On 16/9/07 18:26, "Guy Zana" <guy@neocleus.com> wrote:> That will be "enable_nativedom=1" (without the ''d''). > > Thanks, > Guy. > >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of >> Kay, Allen M >> Sent: Wednesday, September 05, 2007 3:09 AM >> To: xen-devel@lists.xensource.com >> Cc: Guy Zana; Keir Fraser >> Subject: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus >> 1:1 mregedcode for PCI passthrough >> >> The following 6 patches contains merge of Intel VT-d and >> Neocleus'' 1:1 mapping patches for enabling HVM guest direct >> device access that were last submitted around end of May. >> These patches applied cleanly to changeset 15730. >> >> To enabled xen vt-d code, add "ioapic_ack=old" to xen boot >> parameter in grub.conf on systems with VT-d hardware. >> >> To enabled xen 1:1 mapping code, add "enabled_nativedom=1" to >> xen boot parameter in grub.conf. >> >> Signed-off-by: Allen Kay <allen.m.kay@intel.com> >> Signed-off-by: Guy Zana <guy@neocleus.com> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel