SeaBIOS

seabios@seabios.org

3770 discussions

non-emulated AHCI hardware
by Jonathan A. Kollasch 17 Feb '11

17 Feb '11

Hi, I've been trying SeaBIOS's AHCI driver on AMD SB710 hardware under coreboot. Both AMD's AHCI BIOS and NetBSD's ahcisata(4) drivers are happy enough with the hardware's state after coreboot/SeaBIOS. However, SeaBIOS's AHCI driver just falls into a dead loop waiting for commands to complete. This is due to at least two problems. The immediate problem is that we tell the HBA that a Host To Device FIS is 4 dwords. The correct value is 5 dwords if I read the specs right. But, when the H2D FIS length we give to the HBA is 5, I have a more perplexing problem. The machine hardlocks when HBA registers are read after the command has been issued. When I examine the Command List and Receive FIS Area, etc. before and after issuing the command, they have not changed. Jonathan Kollasch

1 1

Re: [SeaBIOS] Next version
by Prasad Joshi 16 Feb '11

16 Feb '11

> 2. Next version (Kevin O'Connor) > ------------------------------ > > Message: 2 > Date: Wed, 16 Feb 2011 01:12:28 -0500 > From: Kevin O'Connor <kevin(a)koconnor.net> > To: seabios(a)seabios.org > Subject: [SeaBIOS] Next version > Message-ID: <20110216061228.GA635(a)morn.localdomain> > Content-Type: text/plain; charset=us-ascii > > I think it's about time to release a new version of SeaBIOS (0.6.2). > Does anyone know of any feature or bug that needs to be addressed > prior to a release? The current PCI memory space is limited to 236MB. It would be good to increase it to at-least 512MB. KVM supports for device assignment to the VM. For most of the PCI devices the 236MB memory might be enough, but when you pass-through a graphics device, this memory is very limited. I don't know if the PCI memory space can be dynamically expanded, but it would be good to increase the PCI memory space to 512MB at-least. > > Also, there have been some inquiries about making a 1.0 release of > SeaBIOS - I'm inclined to bump the major number in the release after > this one (eg, 1.6.3). Let me know if there are any major features > that you'd like to see added prior to a "1.0" release. > > -Kevin >

2 2

Git repo moving
by Kevin O'Connor 16 Feb '11

16 Feb '11

The SeaBIOS git repo can now be accessed via: git clone git://git.seabios.org/seabios.git This is a separate repo from the one located on the linuxtogo.org site. I will maintain the two repos for the next couple of months, but will eventually stop updating the linuxtogo one. The new repo should be faster and much more responsive. This new site (along with the wiki and mail list) is hosted by Coresystems GmbH. Many thanks! -Kevin

1 0

[PATCH] Updated version of OXPCIe serial port support
by Stefan Reinauer 15 Feb '11

15 Feb '11

See patch -- Stefan Reinauer Google Inc.

2 3

Re: [SeaBIOS] Problem with DOS application and 286 DOS Extender application
by Gerhard Wiesinger 14 Feb '11

14 Feb '11

Hello, After some fortune I found out that also Turbo Debugger 286 doesn't work under plain DOS 6.22 (without any memory mananger just pressing F5) or with some memory mananagers (HIMEM.SYS, EMM386, QEMM386). Error message is: Error 266 loading D:\DIR\TD286.EXE into extended memory. So it looks like that there is a major issue with extended memory. Any ideas how to fix or how to find the problem and fix it? Version is latest seabios and QEMU from git as of now (own builds). I'm pretty sure that it is the same reason that the 286 DOS Extender application doesn't work. For full reference of the previously discussed have a look here: http://www.mail-archive.com/qemu-devel@nongnu.org/msg29518.html http://www.mail-archive.com/qemu-devel@nongnu.org/msg29465.html Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ On Wed, 14 Apr 2010, Jan Kiszka wrote: > Jamie Lokier wrote: >> Gerhard Wiesinger wrote: >>> It is a non public, proprietary application which uses the Ergo Computing >>> 286 DOS Extender. I guess some other application which use the same DOS >>> extender have the same problem. So best thing is to find another >>> application which uses the Ergo Computing 286 DOS Extender, too. >> >> The 286 was obsolete 20 years ago, although code depending on it >> persisted for some years after. >> >> I'm fairly sure the number of people using (or trying to use) Qemu >> with 286-specific code is very small indeed, so unfortunately for a >> 286 problem, you will need to help reproduce it as much as you can for >> it to be fixed. > > In some scenarios, we use QEMU in emulation mode for such a legacy guest > (16-bit protected mode), but we mostly run it in KVM mode these days. It > works fairly well under QEMU, but also we did not explore all corner cases. > >> >> Note that Qemu doesn't emulate segments properly even for 32-bit x86 >> code, and 16-bit (286) code depends on that all the more. That may be >> the problem. > > More precisely: QEMU does not check for segment limits. This can be a > problem with buggy or pedantic guests, but usually one tried to avoid > triggering this anyway. I once wrote a crude patch to add this, but it > had significant performance impact and did not properly make use of the > TCG to optimize the checks. You'll find it in the archives (but I guess > it no longer applies). > >> >> Or it may be the "reset using keyboard controller and BIOS" method >> used to switch from protected mode to real mode on a 286 is not >> implemented properly, or is not supported by the BIOS properly. >> >> Or it may simply be a bug in 16-bit task segment switching or >> something like that, which is quite complex and so rarely used that it >> might never have been properly tested. > > Task switching looks fairly stable in QEMU (in contrast to KVM where we > just ran into some more corner cases). > >> >> Did you try running the application under Bochs, which has a more >> accurate emulation of very old x86 CPUs? >> >> -- Jamie >> > > That said, having some test case to reproduce the issue is essential. > I'm willing to have a look if you can provide such thing (publicly or > privately). Before that, you could already try building QEMU with > --enable-debug and run it with "-d exec,int". The generated > /tmp/qemu.log may point out where things go wrong (usually where faults > starts to occur). > > Jan > >

2 2

A question on SeaBIOS PCI Enumeration
by Prasad Joshi 10 Feb '11

10 Feb '11

Hello, I am working on QEMU to pass-through a graphics device. I noticed few problems with PCI enumeration hence I compiled SeaBIOS with more debug information. The PCI enumeration problem seems to be related to BUILS_PCIMEM_SIZE. I keep on getting the error 'increase BUILD_PCIMEM_SIZE and recompile'. This happens when BIOS tries to allocate 128MB for one of the BAR. The code seems to be printing the correct error as, the 128MB naturally aligned memory request can not be satisfied. No problem with this. As I notice on my host machine the same case happens, but host BIOS seems to be allocating 128MB memory from some other region (c0000000-c7ffffff) 02:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B64 [FireGL V3100 (PCIE)] (rev 80) (prog-if 00 [VGA controller]) Region 0: Memory at c0000000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at a000 [size=256] Region 2: Memory at f9cf0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at f9cc0000 [disabled] [size=128K] prasad@prasad-kvm:~$ grep '0000:02' /proc/iomem c0000000-c7ffffff : PCI Bus 0000:02 c0000000-c7ffffff : 0000:02:00.0 f9c00000-f9cfffff : PCI Bus 0000:02 f9cc0000-f9cdffff : 0000:02:00.0 f9ce0000-f9ceffff : 0000:02:00.1 f9cf0000-f9cfffff : 0000:02:00.0 Can SeaBIOS do the same thing? or to put in other words Can SeaBIOS allocate memory from some other region instead of fixed f0000000 to (0xfec00000-1)? Thanks and Regards, Prasad

3 4

IO APIC emulation failure with qemu-kvm
by Ravi Kumar Kulkarni 07 Feb '11

07 Feb '11

Hi all, I'm Initializing the Local and IO APIC for a propeitary operating system running in Virtualized Environment . Im facing some problem with qemu-kvm but the code runs fine with qemu. when i run my kernel image with qemu-kvm it gives emulation error failure trying to execute the code outside ROM or RAM at fec00000(IO APIC base address) but the same code runs fine with qemu. can anyone please point me where might be the problem or how to find out this one? Warm Regards, Ravi Kulkarni.

3 10

Re: [SeaBIOS] [PATCH 2/3] AMD IOMMU support
by Michael S. Tsirkin 06 Feb '11

06 Feb '11

On Fri, Feb 04, 2011 at 01:24:14AM +0200, Eduard - Gabriel Munteanu wrote: > This initializes the AMD IOMMU and creates ACPI tables for it. > > Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu(a)linux360.ro> > --- > src/acpi.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > src/config.h | 3 ++ > src/pci_ids.h | 1 + > src/pci_regs.h | 1 + > src/pciinit.c | 29 +++++++++++++++++++ > 5 files changed, 118 insertions(+), 0 deletions(-) > > diff --git a/src/acpi.c b/src/acpi.c > index 18830dc..fca152c 100644 > --- a/src/acpi.c > +++ b/src/acpi.c > @@ -196,6 +196,36 @@ struct srat_memory_affinity > u32 reserved3[2]; > } PACKED; > > +/* > + * IVRS (I/O Virtualization Reporting Structure) table. > + * > + * Describes the AMD IOMMU, as per: > + * "AMD I/O Virtualization Technology (IOMMU) Specification", rev 1.26 > + */ > + > +struct ivrs_ivhd > +{ > + u8 type; > + u8 flags; > + u16 length; > + u16 devid; > + u16 capab_off; > + u32 iommu_base_low; > + u32 iommu_base_high; > + u16 pci_seg_group; > + u16 iommu_info; > + u32 reserved; > + u8 entry[0]; > +} PACKED; > + > +struct ivrs_table > +{ > + ACPI_TABLE_HEADER_DEF /* ACPI common table header. */ > + u32 iv_info; > + u32 reserved[2]; > + struct ivrs_ivhd ivhd; > +} PACKED; > + prefix with amd_iommu_ or amd_ then ? > #include "acpi-dsdt.hex" > > static void > @@ -579,6 +609,59 @@ build_srat(void) > return srat; > } > > +#define IVRS_SIGNATURE 0x53525649 // IVRS > +#define IVRS_MAX_DEVS 32 > +static void * > +build_ivrs(void) > +{ > + int iommu_bdf, iommu_cap; > + int bdf, max, i; > + struct ivrs_table *ivrs; > + struct ivrs_ivhd *ivhd; > + > + /* Note this currently works for a single IOMMU! */ Meant to be a FIXME? How hard is it to fix? Just stick this in a loop? > + iommu_bdf = pci_find_class(PCI_CLASS_SYSTEM_IOMMU); > + if (iommu_bdf < 0) > + return NULL; > + iommu_cap = pci_find_capability(iommu_bdf, PCI_CAP_ID_SEC); > + if (iommu_cap < 0) > + return NULL; > + > + ivrs = malloc_high(sizeof(struct ivrs_table) + 4 * IVRS_MAX_DEVS); > + ivrs->iv_info = pci_config_readw(iommu_bdf, iommu_cap + 0x12) & ~0x000F; > + > + ivhd = &ivrs->ivhd; > + ivhd->type = 0x10; > + ivhd->flags = 0; > + ivhd->length = sizeof(struct ivrs_ivhd); > + ivhd->devid = iommu_bdf; > + ivhd->capab_off = iommu_cap; > + ivhd->iommu_base_low = pci_config_readl(iommu_bdf, iommu_cap + 0x04) & > + 0xFFFFFFFE; > + ivhd->iommu_base_high = pci_config_readl(iommu_bdf, iommu_cap + 0x08); > + ivhd->pci_seg_group = 0; > + ivhd->iommu_info = 0; > + ivhd->reserved = 0; > + > + i = 0; > + foreachpci(bdf, max) { > + if (bdf == ivhd->devid) > + continue; > + ivhd->entry[4 * i + 0] = 2; > + ivhd->entry[4 * i + 1] = bdf & 0xFF; > + ivhd->entry[4 * i + 2] = (bdf >> 8) & 0xFF; > + ivhd->entry[4 * i + 3] = ~(1 << 3); > + ivhd->length += 4; > + if (++i >= IVRS_MAX_DEVS) > + break; > + } > + > + build_header((void *) ivrs, IVRS_SIGNATURE, > + sizeof(struct ivrs_table) + 4 * i, 1); > + > + return ivrs; > +} > + > static const struct pci_device_id acpi_find_tbl[] = { > /* PIIX4 Power Management device. */ > PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_3, NULL), > @@ -625,6 +708,7 @@ acpi_bios_init(void) > ACPI_INIT_TABLE(build_madt()); > ACPI_INIT_TABLE(build_hpet()); > ACPI_INIT_TABLE(build_srat()); > + ACPI_INIT_TABLE(build_ivrs()); > > u16 i, external_tables = qemu_cfg_acpi_additional_tables(); > > diff --git a/src/config.h b/src/config.h > index 6356941..0ba5723 100644 > --- a/src/config.h > +++ b/src/config.h > @@ -172,6 +172,9 @@ > #define BUILD_APIC_ADDR 0xfee00000 > #define BUILD_IOAPIC_ADDR 0xfec00000 > > +#define BUILD_AMD_IOMMU_START 0xfed00000 > +#define BUILD_AMD_IOMMU_END 0xfee00000 /* BUILD_APIC_ADDR */ > + > #define BUILD_SMM_INIT_ADDR 0x38000 > #define BUILD_SMM_ADDR 0xa8000 > #define BUILD_SMM_SIZE 0x8000 > diff --git a/src/pci_ids.h b/src/pci_ids.h > index e1cded2..3cc3c6e 100644 > --- a/src/pci_ids.h > +++ b/src/pci_ids.h > @@ -72,6 +72,7 @@ > #define PCI_CLASS_SYSTEM_RTC 0x0803 > #define PCI_CLASS_SYSTEM_PCI_HOTPLUG 0x0804 > #define PCI_CLASS_SYSTEM_SDHCI 0x0805 > +#define PCI_CLASS_SYSTEM_IOMMU 0x0806 > #define PCI_CLASS_SYSTEM_OTHER 0x0880 > > #define PCI_BASE_CLASS_INPUT 0x09 > diff --git a/src/pci_regs.h b/src/pci_regs.h > index e5effd4..bfac824 100644 > --- a/src/pci_regs.h > +++ b/src/pci_regs.h > @@ -208,6 +208,7 @@ > #define PCI_CAP_ID_SHPC 0x0C /* PCI Standard Hot-Plug Controller */ > #define PCI_CAP_ID_SSVID 0x0D /* Bridge subsystem vendor/device ID */ > #define PCI_CAP_ID_AGP3 0x0E /* AGP Target PCI-PCI bridge */ > +#define PCI_CAP_ID_SEC 0x0F /* Secure Device (AMD IOMMU) */ > #define PCI_CAP_ID_EXP 0x10 /* PCI Express */ > #define PCI_CAP_ID_MSIX 0x11 /* MSI-X */ > #define PCI_CAP_LIST_NEXT 1 /* Next capability in the list */ > diff --git a/src/pciinit.c b/src/pciinit.c > index ee2e72d..4ebcfbe 100644 > --- a/src/pciinit.c > +++ b/src/pciinit.c > @@ -21,6 +21,8 @@ static struct pci_region pci_bios_io_region; > static struct pci_region pci_bios_mem_region; > static struct pci_region pci_bios_prefmem_region; > > +static u32 amd_iommu_addr; > + > /* host irqs corresponding to PCI irqs A-D */ > const u8 pci_irqs[4] = { > 10, 10, 11, 11 > @@ -256,6 +258,27 @@ static void apple_macio_init(u16 bdf, void *arg) > pci_set_io_region_addr(bdf, 0, 0x80800000); > } > > +static void amd_iommu_init(u16 bdf, void *arg) > +{ > + int cap; > + u32 base_addr; > + > + cap = pci_find_capability(bdf, PCI_CAP_ID_SEC); > + if (cap < 0) { > + return; > + } There actually can be multiple instances of this capability according to spec. Do we care? > + > + if (amd_iommu_addr >= BUILD_AMD_IOMMU_END) { > + return; > + } > + base_addr = amd_iommu_addr; > + amd_iommu_addr += 0x4000; > + > + pci_config_writel(bdf, cap + 0x0C, 0); > + pci_config_writel(bdf, cap + 0x08, 0); > + pci_config_writel(bdf, cap + 0x04, base_addr | 1); > +} > + > static const struct pci_device_id pci_class_tbl[] = { > /* STORAGE IDE */ > PCI_DEVICE_CLASS(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_1, > @@ -279,6 +302,10 @@ static const struct pci_device_id pci_class_tbl[] = { > PCI_DEVICE_CLASS(PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_BRIDGE_PCI, > pci_bios_init_device_bridge), > > + /* AMD IOMMU */ Makes sense to limit to AMD vendor id? > + PCI_DEVICE_CLASS(PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_SYSTEM_IOMMU, > + amd_iommu_init), > + > /* default */ > PCI_DEVICE(PCI_ANY_ID, PCI_ANY_ID, pci_bios_allocate_regions), > > @@ -408,6 +435,8 @@ pci_setup(void) > pci_region_init(&pci_bios_prefmem_region, > BUILD_PCIPREFMEM_START, BUILD_PCIPREFMEM_END - 1); > > + amd_iommu_addr = BUILD_AMD_IOMMU_START; > + > pci_bios_init_bus(); > > int bdf, max; > -- > 1.7.3.4

2 2

Re: [SeaBIOS] [PATCH 01/13] Generic DMA memory access interface
by Michael S. Tsirkin 06 Feb '11

06 Feb '11

On Fri, Feb 04, 2011 at 01:32:55AM +0200, Eduard - Gabriel Munteanu wrote: > This introduces replacements for memory access functions like > cpu_physical_memory_read(). The new interface can handle address > translation and access checking through an IOMMU. > > Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu(a)linux360.ro> > --- > Makefile.target | 2 +- > hw/dma_rw.c | 124 +++++++++++++++++++++++++++++++++++++++++++ > hw/dma_rw.h | 157 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 282 insertions(+), 1 deletions(-) > create mode 100644 hw/dma_rw.c > create mode 100644 hw/dma_rw.h > > diff --git a/Makefile.target b/Makefile.target > index e15b1c4..e5817ab 100644 > --- a/Makefile.target > +++ b/Makefile.target > @@ -218,7 +218,7 @@ obj-i386-y += cirrus_vga.o apic.o ioapic.o piix_pci.o > obj-i386-y += vmmouse.o vmport.o hpet.o applesmc.o > obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o > obj-i386-y += debugcon.o multiboot.o > -obj-i386-y += pc_piix.o > +obj-i386-y += pc_piix.o dma_rw.o Does this need to be target specific? > obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o > > # shared objects > diff --git a/hw/dma_rw.c b/hw/dma_rw.c > new file mode 100644 > index 0000000..ef8e7f8 > --- /dev/null > +++ b/hw/dma_rw.c > @@ -0,0 +1,124 @@ > +/* > + * Generic DMA memory access interface. > + * > + * Copyright (c) 2011 Eduard - Gabriel Munteanu > + * > + * Permission is hereby granted, free of charge, to any person obtaining a copy > + * of this software and associated documentation files (the "Software"), to deal > + * in the Software without restriction, including without limitation the rights > + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell > + * copies of the Software, and to permit persons to whom the Software is > + * furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, > + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN > + * THE SOFTWARE. > + */ > + > +#include "dma_rw.h" > +#include "range.h" > + > +static void dma_register_memory_map(DMADevice *dev, > + dma_addr_t addr, > + dma_addr_t len, > + target_phys_addr_t paddr, > + DMAInvalidateMapFunc *invalidate, > + void *invalidate_opaque) > +{ > + DMAMemoryMap *map; > + > + map = qemu_malloc(sizeof(DMAMemoryMap)); > + map->addr = addr; > + map->len = len; > + map->paddr = paddr; > + map->invalidate = invalidate; > + map->invalidate_opaque = invalidate_opaque; > + > + QLIST_INSERT_HEAD(&dev->mmu->memory_maps, map, list); > +} > + > +static void dma_unregister_memory_map(DMADevice *dev, > + target_phys_addr_t paddr, > + dma_addr_t len) > +{ > + DMAMemoryMap *map; > + > + QLIST_FOREACH(map, &dev->mmu->memory_maps, list) { > + if (map->paddr == paddr && map->len == len) { > + QLIST_REMOVE(map, list); > + free(map); > + } > + } > +} > + > +void dma_invalidate_memory_range(DMADevice *dev, > + dma_addr_t addr, > + dma_addr_t len) > +{ > + DMAMemoryMap *map; > + > + QLIST_FOREACH(map, &dev->mmu->memory_maps, list) { > + if (ranges_overlap(addr, len, map->addr, map->len)) { > + map->invalidate(map->invalidate_opaque); > + QLIST_REMOVE(map, list); > + free(map); > + } > + } > +} > + > +void *dma_memory_map(DMADevice *dev, > + DMAInvalidateMapFunc *cb, > + void *opaque, > + dma_addr_t addr, > + dma_addr_t *len, > + int is_write) > +{ > + int err; > + target_phys_addr_t paddr, plen; > + > + if (!dev || !dev->mmu) { > + return cpu_physical_memory_map(addr, len, is_write); > + } > + > + plen = *len; > + err = dev->mmu->translate(dev, addr, &paddr, &plen, is_write); > + if (err) { > + return NULL; > + } > + > + /* > + * If this is true, the virtual region is contiguous, > + * but the translated physical region isn't. We just > + * clamp *len, much like cpu_physical_memory_map() does. > + */ > + if (plen < *len) { > + *len = plen; > + } > + > + /* We treat maps as remote TLBs to cope with stuff like AIO. */ > + if (cb) { > + dma_register_memory_map(dev, addr, *len, paddr, cb, opaque); > + } > + > + return cpu_physical_memory_map(paddr, len, is_write); > +} > + > +void dma_memory_unmap(DMADevice *dev, > + void *buffer, > + dma_addr_t len, > + int is_write, > + dma_addr_t access_len) > +{ > + cpu_physical_memory_unmap(buffer, len, is_write, access_len); > + if (dev && dev->mmu) { > + dma_unregister_memory_map(dev, (target_phys_addr_t) buffer, len); > + } > +} > + > diff --git a/hw/dma_rw.h b/hw/dma_rw.h Can we have a configure option to disable this at compile time? Add stubs to avoid propagating ifdefs all over the code. > new file mode 100644 > index 0000000..bc93511 > --- /dev/null > +++ b/hw/dma_rw.h > @@ -0,0 +1,157 @@ > +#ifndef DMA_RW_H > +#define DMA_RW_H > + > +#include "qemu-common.h" > + > +typedef uint64_t dma_addr_t; > + > +typedef struct DMAMmu DMAMmu; > +typedef struct DMADevice DMADevice; > +typedef struct DMAMemoryMap DMAMemoryMap; > + > +typedef int DMATranslateFunc(DMADevice *dev, > + dma_addr_t addr, > + dma_addr_t *paddr, > + dma_addr_t *len, > + int is_write); > + > +typedef void DMAInvalidateMapFunc(void *); > + > +struct DMAMmu { > + DeviceState *iommu; > + DMATranslateFunc *translate; > + QLIST_HEAD(memory_maps, DMAMemoryMap) memory_maps; > +}; > + > +struct DMADevice { > + DMAMmu *mmu; > +}; > + > +struct DMAMemoryMap { > + dma_addr_t addr; > + dma_addr_t len; > + target_phys_addr_t paddr; > + DMAInvalidateMapFunc *invalidate; > + void *invalidate_opaque; > + > + QLIST_ENTRY(DMAMemoryMap) list; > +}; > + > +static inline void dma_memory_rw(DMADevice *dev, > + dma_addr_t addr, > + void *buf, > + dma_addr_t len, > + int is_write) > +{ > + dma_addr_t paddr, plen; > + int err; > + > + /* > + * Fast-path non-iommu. > + * More importantly, makes it obvious what this function does. > + */ > + if (!dev || !dev->mmu) { > + cpu_physical_memory_rw(addr, buf, plen, is_write); > + return; > + } > + > + while (len) { > + err = dev->mmu->translate(dev, addr, &paddr, &plen, is_write); > + if (err) { > + return; > + } > + > + /* The translation might be valid for larger regions. */ > + if (plen > len) { > + plen = len; > + } > + > + cpu_physical_memory_rw(paddr, buf, plen, is_write); > + > + len -= plen; > + addr += plen; > + buf += plen; > + } > +} > + > +static inline void dma_memory_read(DMADevice *dev, > + dma_addr_t addr, > + void *buf, > + dma_addr_t len) > +{ > + dma_memory_rw(dev, addr, buf, len, 0); > +} > + > +static inline void dma_memory_write(DMADevice *dev, > + dma_addr_t addr, > + const void *buf, > + dma_addr_t len) > +{ > + dma_memory_rw(dev, addr, (void *) buf, len, 1); > +} > + > +void *dma_memory_map(DMADevice *dev, > + DMAInvalidateMapFunc *cb, > + void *opaque, > + dma_addr_t addr, > + dma_addr_t *len, > + int is_write); > +void dma_memory_unmap(DMADevice *dev, > + void *buffer, > + dma_addr_t len, > + int is_write, > + dma_addr_t access_len); > + > + > +void dma_invalidate_memory_range(DMADevice *dev, > + dma_addr_t addr, > + dma_addr_t len); > + > + > +#define DEFINE_DMA_LD(suffix, size) \ > +static inline uint##size##_t \ > +dma_ld##suffix(DMADevice *dev, dma_addr_t addr) \ > +{ \ > + int err; \ > + dma_addr_t paddr, plen; \ > + \ > + if (!dev || !dev->mmu) { \ > + return ld##suffix##_phys(addr); \ > + } \ > + \ > + err = dev->mmu->translate(dev, addr, &paddr, &plen, 0); \ > + if (err || (plen < size / 8)) \ > + return 0; \ > + \ > + return ld##suffix##_phys(paddr); \ > +} > + > +#define DEFINE_DMA_ST(suffix, size) \ > +static inline void \ > +dma_st##suffix(DMADevice *dev, dma_addr_t addr, uint##size##_t val) \ > +{ \ > + int err; \ > + target_phys_addr_t paddr, plen; \ > + \ > + if (!dev || !dev->mmu) { \ > + st##suffix##_phys(addr, val); \ > + return; \ > + } \ > + err = dev->mmu->translate(dev, addr, &paddr, &plen, 1); \ > + if (err || (plen < size / 8)) \ > + return; \ > + \ > + st##suffix##_phys(paddr, val); \ > +} > + > +DEFINE_DMA_LD(ub, 8) > +DEFINE_DMA_LD(uw, 16) > +DEFINE_DMA_LD(l, 32) > +DEFINE_DMA_LD(q, 64) > + > +DEFINE_DMA_ST(b, 8) > +DEFINE_DMA_ST(w, 16) > +DEFINE_DMA_ST(l, 32) > +DEFINE_DMA_ST(q, 64) > + > +#endif > -- > 1.7.3.4

1 0

Re: [SeaBIOS] [PATCH 04/13] ide: use the DMA memory access interface for PCI IDE controllers
by Michael S. Tsirkin 06 Feb '11

06 Feb '11

On Fri, Feb 04, 2011 at 01:32:58AM +0200, Eduard - Gabriel Munteanu wrote: > Emulated PCI IDE controllers now use the memory access interface. This > also allows an emulated IOMMU to translate and check accesses. > > Map invalidation results in cancelling DMA transfers. Since the guest OS > can't properly recover the DMA results in case the mapping is changed, > this is a fairly good approximation. > > Note this doesn't handle AHCI emulation yet! > > Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu(a)linux360.ro> How about not changing ahci then, and failing initialization if an mmu is present? > --- > dma-helpers.c | 23 ++++++++++++++++++----- > dma.h | 4 +++- > hw/ide/ahci.c | 3 ++- > hw/ide/internal.h | 1 + > hw/ide/macio.c | 4 ++-- > hw/ide/pci.c | 18 +++++++++++------- > 6 files changed, 37 insertions(+), 16 deletions(-) > > diff --git a/dma-helpers.c b/dma-helpers.c > index 712ed89..29a74a4 100644 > --- a/dma-helpers.c > +++ b/dma-helpers.c > @@ -10,12 +10,13 @@ > #include "dma.h" > #include "block_int.h" > > -void qemu_sglist_init(QEMUSGList *qsg, int alloc_hint) > +void qemu_sglist_init(QEMUSGList *qsg, int alloc_hint, DMADevice *dma) > { > qsg->sg = qemu_malloc(alloc_hint * sizeof(ScatterGatherEntry)); > qsg->nsg = 0; > qsg->nalloc = alloc_hint; > qsg->size = 0; > + qsg->dma = dma; > } > > void qemu_sglist_add(QEMUSGList *qsg, target_phys_addr_t base, > @@ -73,12 +74,23 @@ static void dma_bdrv_unmap(DMAAIOCB *dbs) > int i; > > for (i = 0; i < dbs->iov.niov; ++i) { > - cpu_physical_memory_unmap(dbs->iov.iov[i].iov_base, > - dbs->iov.iov[i].iov_len, !dbs->is_write, > - dbs->iov.iov[i].iov_len); > + dma_memory_unmap(dbs->sg->dma, > + dbs->iov.iov[i].iov_base, > + dbs->iov.iov[i].iov_len, !dbs->is_write, > + dbs->iov.iov[i].iov_len); > } > } > > +static void dma_bdrv_cancel(void *opaque) > +{ > + DMAAIOCB *dbs = opaque; > + > + bdrv_aio_cancel(dbs->acb); > + dma_bdrv_unmap(dbs); > + qemu_iovec_destroy(&dbs->iov); > + qemu_aio_release(dbs); > +} > + > static void dma_bdrv_cb(void *opaque, int ret) > { > DMAAIOCB *dbs = (DMAAIOCB *)opaque; > @@ -100,7 +112,8 @@ static void dma_bdrv_cb(void *opaque, int ret) > while (dbs->sg_cur_index < dbs->sg->nsg) { > cur_addr = dbs->sg->sg[dbs->sg_cur_index].base + dbs->sg_cur_byte; > cur_len = dbs->sg->sg[dbs->sg_cur_index].len - dbs->sg_cur_byte; > - mem = cpu_physical_memory_map(cur_addr, &cur_len, !dbs->is_write); > + mem = dma_memory_map(dbs->sg->dma, dma_bdrv_cancel, dbs, > + cur_addr, &cur_len, !dbs->is_write); > if (!mem) > break; > qemu_iovec_add(&dbs->iov, mem, cur_len); > diff --git a/dma.h b/dma.h > index f3bb275..2417b32 100644 > --- a/dma.h > +++ b/dma.h > @@ -14,6 +14,7 @@ > //#include "cpu.h" > #include "hw/hw.h" > #include "block.h" > +#include "hw/dma_rw.h" > > typedef struct { > target_phys_addr_t base; > @@ -25,9 +26,10 @@ typedef struct { > int nsg; > int nalloc; > target_phys_addr_t size; > + DMADevice *dma; > } QEMUSGList; > > -void qemu_sglist_init(QEMUSGList *qsg, int alloc_hint); > +void qemu_sglist_init(QEMUSGList *qsg, int alloc_hint, DMADevice *dma); > void qemu_sglist_add(QEMUSGList *qsg, target_phys_addr_t base, > target_phys_addr_t len); > void qemu_sglist_destroy(QEMUSGList *qsg); > diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c > index 968fdce..aea06a9 100644 > --- a/hw/ide/ahci.c > +++ b/hw/ide/ahci.c > @@ -993,7 +993,8 @@ static int ahci_populate_sglist(AHCIDevice *ad, QEMUSGList *sglist) > if (sglist_alloc_hint > 0) { > AHCI_SG *tbl = (AHCI_SG *)prdt; > > - qemu_sglist_init(sglist, sglist_alloc_hint); > + /* FIXME: pass a proper DMADevice. */ > + qemu_sglist_init(sglist, sglist_alloc_hint, NULL); > for (i = 0; i < sglist_alloc_hint; i++) { > /* flags_size is zero-based */ > qemu_sglist_add(sglist, le64_to_cpu(tbl[i].addr), > diff --git a/hw/ide/internal.h b/hw/ide/internal.h > index 697c3b4..3d3d5db 100644 > --- a/hw/ide/internal.h > +++ b/hw/ide/internal.h > @@ -468,6 +468,7 @@ struct IDEDMA { > struct iovec iov; > QEMUIOVector qiov; > BlockDriverAIOCB *aiocb; > + DMADevice *dev; > }; > > struct IDEBus { > diff --git a/hw/ide/macio.c b/hw/ide/macio.c > index c1b4caa..654ae7c 100644 > --- a/hw/ide/macio.c > +++ b/hw/ide/macio.c > @@ -79,7 +79,7 @@ static void pmac_ide_atapi_transfer_cb(void *opaque, int ret) > > s->io_buffer_size = io->len; > > - qemu_sglist_init(&s->sg, io->len / MACIO_PAGE_SIZE + 1); > + qemu_sglist_init(&s->sg, io->len / MACIO_PAGE_SIZE + 1, NULL); > qemu_sglist_add(&s->sg, io->addr, io->len); > io->addr += io->len; > io->len = 0; > @@ -141,7 +141,7 @@ static void pmac_ide_transfer_cb(void *opaque, int ret) > s->io_buffer_index = 0; > s->io_buffer_size = io->len; > > - qemu_sglist_init(&s->sg, io->len / MACIO_PAGE_SIZE + 1); > + qemu_sglist_init(&s->sg, io->len / MACIO_PAGE_SIZE + 1, NULL); > qemu_sglist_add(&s->sg, io->addr, io->len); > io->addr += io->len; > io->len = 0; > diff --git a/hw/ide/pci.c b/hw/ide/pci.c > index 510b2de..e3432c4 100644 > --- a/hw/ide/pci.c > +++ b/hw/ide/pci.c > @@ -64,7 +64,8 @@ static int bmdma_prepare_buf(IDEDMA *dma, int is_write) > } prd; > int l, len; > > - qemu_sglist_init(&s->sg, s->nsector / (BMDMA_PAGE_SIZE / 512) + 1); > + qemu_sglist_init(&s->sg, > + s->nsector / (BMDMA_PAGE_SIZE / 512) + 1, dma->dev); > s->io_buffer_size = 0; > for(;;) { > if (bm->cur_prd_len == 0) { > @@ -72,7 +73,7 @@ static int bmdma_prepare_buf(IDEDMA *dma, int is_write) > if (bm->cur_prd_last || > (bm->cur_addr - bm->addr) >= BMDMA_PAGE_SIZE) > return s->io_buffer_size != 0; > - cpu_physical_memory_read(bm->cur_addr, (uint8_t *)&prd, 8); > + dma_memory_read(dma->dev, bm->cur_addr, (uint8_t *)&prd, 8); > bm->cur_addr += 8; > prd.addr = le32_to_cpu(prd.addr); > prd.size = le32_to_cpu(prd.size); > @@ -114,7 +115,7 @@ static int bmdma_rw_buf(IDEDMA *dma, int is_write) > if (bm->cur_prd_last || > (bm->cur_addr - bm->addr) >= BMDMA_PAGE_SIZE) > return 0; > - cpu_physical_memory_read(bm->cur_addr, (uint8_t *)&prd, 8); > + dma_memory_read(dma->dev, bm->cur_addr, (uint8_t *)&prd, 8); > bm->cur_addr += 8; > prd.addr = le32_to_cpu(prd.addr); > prd.size = le32_to_cpu(prd.size); > @@ -129,11 +130,11 @@ static int bmdma_rw_buf(IDEDMA *dma, int is_write) > l = bm->cur_prd_len; > if (l > 0) { > if (is_write) { > - cpu_physical_memory_write(bm->cur_prd_addr, > - s->io_buffer + s->io_buffer_index, l); > + dma_memory_write(dma->dev, bm->cur_prd_addr, > + s->io_buffer + s->io_buffer_index, l); > } else { > - cpu_physical_memory_read(bm->cur_prd_addr, > - s->io_buffer + s->io_buffer_index, l); > + dma_memory_read(dma->dev, bm->cur_prd_addr, > + s->io_buffer + s->io_buffer_index, l); > } > bm->cur_prd_addr += l; > bm->cur_prd_len -= l; > @@ -444,6 +445,9 @@ void pci_ide_create_devs(PCIDevice *dev, DriveInfo **hd_table) > continue; > ide_create_drive(d->bus+bus[i], unit[i], hd_table[i]); > } > + > + d->bmdma[0].dma.dev = &dev->dma; > + d->bmdma[1].dma.dev = &dev->dma; > } > > static const struct IDEDMAOps bmdma_ops = { > -- > 1.7.3.4

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS