I apologize for the tardy acknowledgement to the additional responses. I caught a really nasty upper respiratory infection (vernacular: a cold) on New Year’s Eve and the only thing I did for two weeks was sleep 20+ hours/day.
An excellent suggestion. Thank You. I’ll go check out the archives and sign up for the mailing list. I’ll just lurk for awhile to get a sense for the accepted cultural norms prior to speaking up.
Ah yes, the time-honored axiom, “If it ain’t broke, don’t fix it.” A philosophy which I heartily endorse. But the corollary is “If you want to use it, but it’s broke, then fix it.”
I omitted a lot of extraneous data from my original and follow-up posts because it didn’t seem pertinent to the query I was posing. Among that data was timing for a simple performance measurement experiment I performed. In an AMD system there are three different methods of achieving the IOMMU functionality, they are:
- SWIOTLB: The data is moved from low (<4GB) memory to the pages mapped into the space allocated to the relevant task (in this case, a VM) entirely via code executed by the host CPU as a kernel-mode function.
- GART: In this case, the data is moved with a hardware assist provided by re-purposing the GART.
- AMD-Vi: Full hardware DMA of data between the peripheral (like a disk drive) and the memory area allocated to the task which requested the data. Physical<->virtual address remapping is provided in the IOTLB table entries in addition to priviledge protection mechanisms (i.e., does this task have appropriate permissions to initiate such a request).
I had assumed that the performance of those three methodologies would be that #1 would be slowest and #3 would be fastest, but that’s not what I empirically found in my system.
I installed 64-bit Mandriva 2011 as a VM under KVM. I then measured the boot times, from kernel launch via GRUB to login screen of that system. In all cases, I performed a cold boot of both the Physical and Virtual systems. This is what I saw:
Kernel Args Time
iommu=soft,noagp,noaperture 26.87S
iommu=memaper 33.84S
<none> 33.80S
In all cases, the “Kernel Args” are the IOMMU-related parameters I passed to the host machine (openSUSE 12.1) kernel. In cases 1 & 2, the IOMMU (AMD-Vi) was disabled in the (host machine) BIOS. I case 3, the IOMMU was enabled in the BIOS. As you can see, the software implementation was actually faster than the hardware alternatives and there was no difference between the GART and the AMD-Vi instances. None of this passes the common sense test, nor is it consistent with results published by AMD (and others) describing the benefits of the AMD-Vi technology. This leads me to believe that something is, indeed, broken with the BIOS in my sysem.
I had noticed the newly formed Virtualization forum and will doubtless be spending time there to ensure that I correctly utilize the pass-through functionality of the AMD-Vi. But I first need to get the AMD-Vi IOMMU working on my system. I’m currently convinced that it’s not working.
I’ve been happily using VirtualBox on openSUSE since 11.1. I like it. On the other hand, this is the first piece of hardware I’ve owned that was even capable of using KVM (or Xen). So I think I’ll do my own evaluation, provided I can get the hardware to work like it’s supposed to.
Again, thanks to all for your replies. I’ve got a lot of work ahead of me when I get back to working on that system. And I now have some different avenues to travel in my quest for knowledge.
ron
