Re: [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough

[John Byrne <john.l.byrne@hp.com>]

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
>>>
>