[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Latest AMD, IOMMU Security Change causing CPU0 Panic and general Problems with AMD+IOMMU changes



Hi,

I finally had the chance to test the new patches and it's great that
they made it to the main rep already. With the new patches (rev 26532
xen-unstable) I neither have the boot time crash nore the disk access
issue I reported above.

Unfortunatly, the changes disable my IOMMU rendering pci and vga
passthrough unusable for me. Now, I might have missed something, but
what exactly is the point of this at all? My Xen is running fine with
AMD IOMMU for years now but if i still want to do this, I have to
revert changes 26532, 26531, 26519, 26518 and 25617 (basically all the
AMD/IOMMU changes).

When don't reverting them, I get the AMD-Vi is disabled messages at
boot time and an error message for every PCI device I try to assign.

Is there any chance you might rethink the whole approach? Because pci
passthrough is something i heavily use..



xl dmesg output for AMD-Vi:

(XEN) Initing memory sharing.
(XEN) AMD Fam10h machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff
(XEN) PCI: Not using MCFG for segment 0000 bus 00-ff
(XEN) IVHD Error: no information for IO-APIC 0x6
(XEN) AMD-Vi: Error initialization
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1


Output when starting the domU with PCI passthrough (every pci-failed
line is for one pci device i try to pass):

root@Server:~/xen/domu# xl create WORK
Parsing config from WORK
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019e9a8
  Modules:       0000000000000000->0000000000000000
  TOTAL:         0000000000000000->000000013f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000003
libxl: error: libxl_pci.c:948:do_pci_add: xc_assign_device failed
libxl: error: libxl_pci.c:948:do_pci_add: xc_assign_device failed
libxl: error: libxl_pci.c:989:libxl__device_pci_reset: The kernel
doesn't support reset from sysfs for PCI device 0000:00:12.0
libxl: error: libxl_pci.c:948:do_pci_add: xc_assign_device failed
libxl: error: libxl_pci.c:948:do_pci_add: xc_assign_device failed
libxl: error: libxl_pci.c:989:libxl__device_pci_reset: The kernel
doesn't support reset from sysfs for PCI device 0000:00:13.0
libxl: error: libxl_pci.c:948:do_pci_add: xc_assign_device failed
libxl: error: libxl_pci.c:948:do_pci_add: xc_assign_device failed
libxl: error: libxl_pci.c:948:do_pci_add: xc_assign_device failed
libxl: error: libxl_pci.c:989:libxl__device_pci_reset: The kernel
doesn't support reset from sysfs for PCI device 0000:00:14.5
libxl: error: libxl_pci.c:948:do_pci_add: xc_assign_device failed
libxl: error: libxl_pci.c:989:libxl__device_pci_reset: The kernel
doesn't support reset from sysfs for PCI device 0000:00:16.0
libxl: error: libxl_pci.c:948:do_pci_add: xc_assign_device failed
libxl: error: libxl_pci.c:948:do_pci_add: xc_assign_device failed
Daemon running with PID 3448

The 'kernel doesn't support reset from sysfs' messages are normal and
don't indicate any malfunction.


2013/2/13 Jan Beulich <JBeulich@xxxxxxxx>:
>>>> On 13.02.13 at 09:27, Matthias <matthias.kannenberg@xxxxxxxxxxxxxx> wrote:
>> Do you have any idea when all the new AMD/IOMMU patches will be
>> included in the unstable repo? Since i got some issues with the other
>> patches as well and have seen you got around 10 patches for fixing
>> this in xen-devel, it would generally like the idea of having all the
>> fixes in the hg repo then patching everything by hand.
>
> This largely depends on the pending patches getting reviewed
> and acked appropriately. But it's three patches only according to
> my counting, one of which being in need of a conceptual decision
> (i.e. unlikely to go in very quickly), and out of those three only
> one is a regression fix (the one I pointed you to).
>
> Jan
>

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.