Re: [RFC PATCH 0/7] Beginning implementing the AMD IOMMU emulation
On 03/30/2010 10:40 PM, Joerg Roedel wrote: In short, this demonstrates a mechanism of inserting ACPI tables without modifying SeaBIOS or other BIOS implementations. I also have a SeaBIOS equivalent, but I think this approach is better, at least at the moment. I like the approach implemented in this patchset because of its simplicity. The right place for building acpi tables is the bios, though. I am fine with both ways. Anthony, Avi, what do you think about it? I agree. Let qemu emulate the hardware, build the tables in the BIOS. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] Beginning implementing the AMD IOMMU emulation
Hello Eduard, On Tue, Mar 30, 2010 at 11:20:01AM +0300, Eduard - Gabriel Munteanu wrote: > This patchset is intended to provide a start for implementing the > emulation of the AMD IOMMU. For those who aren't aware yet, I intend > to participate as a student in GSoC 2010. Great. This is a good start. > In short, this demonstrates a mechanism of inserting ACPI tables without > modifying SeaBIOS or other BIOS implementations. I also have a SeaBIOS > equivalent, but I think this approach is better, at least at the moment. I like the approach implemented in this patchset because of its simplicity. The right place for building acpi tables is the bios, though. I am fine with both ways. Anthony, Avi, what do you think about it? > I wouldn't merge this patchset yet, at least stuff after the first patch, > until it accumulates more work. I also didn't test loading ACPI tables from > the command line after these modifications. When Linux finds an IVRS table it expects that there is a working AMD IOMMU so you should change this patchset so that the ACPI table is enabled later when the hardware emulation is working. That will keep this work bisectable. As the next step I suggest you to implement an AMD IOMMU pci device with the config space, capability and the mmio register space. Regards, Joerg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/7] Beginning implementing the AMD IOMMU emulation
Hi everybody, This patchset is intended to provide a start for implementing the emulation of the AMD IOMMU. For those who aren't aware yet, I intend to participate as a student in GSoC 2010. The patches are meant to be applied on top of qemu-kvm. In short, this demonstrates a mechanism of inserting ACPI tables without modifying SeaBIOS or other BIOS implementations. I also have a SeaBIOS equivalent, but I think this approach is better, at least at the moment. To test, simply boot a Linux kernel inside KVM and look in dmesg for the IVRS table. I wouldn't merge this patchset yet, at least stuff after the first patch, until it accumulates more work. I also didn't test loading ACPI tables from the command line after these modifications. I'd appreciate comments on these patches. Cheers, Eduard Eduard - Gabriel Munteanu (7): acpi: qemu_realloc() might return a different pointer acpi: split and rename acpi_table_add() acpi: move table header definition into pc.h sparc: rename hw/iommu.c x86-64: AMD IOMMU stub acpi: cleanup acpi_checksum() acpi: fix bug in acpi_checksum() caused by garbage in checksum field Makefile.target |3 +- hw/acpi.c | 83 +++- hw/amd_iommu.c| 103 + hw/pc.c |2 + hw/pc.h | 20 - hw/{iommu.c => sparc_iommu.c} |0 hw/sun4m.h|2 +- vl.c |2 +- 8 files changed, 177 insertions(+), 38 deletions(-) create mode 100644 hw/amd_iommu.c rename hw/{iommu.c => sparc_iommu.c} (100%) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html