qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] ahci: map memory via device's address space ins


From: John Snow
Subject: Re: [Qemu-devel] [PATCH] ahci: map memory via device's address space instead of address_space_memory
Date: Thu, 26 Feb 2015 17:31:34 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

(Please don't top-post on qemu-devel: gmail is kind of awful about this, but if you expand the conversation while in-reply, you can edit beneath the quote instead of above.)

On 02/26/2015 04:31 PM, Jordan Hargrave wrote:
The problem is the FIS registers have stale data.

SeaBIOS initialization leaves the registers:
PORT_FIS_ADDR = 0x7fae0000
PORT_FIS_ADDR_HI = 0x0

My OS initializes DMAR page tables and then enables the IOMMU translation.
Then OS initializes AHCI driver.  Writes VIRTUAL DMA to FIS registers.
eg. FIS DMA address is 0x10000 (maps to some hardware physical address
via iommu)

The OS writes 0x00 PORT_FIS_ADDR_HI -> qemu calls map_page (0x00 << 32)
| 0x7fae0000... 0x7fae0000 is stale, and is not in the IOMMU page map.
Causes a non-recoverable IOMMU fault.



OK, I see.

We can probably fix this by delaying the map and having it map on-demand before first access, setting a dirty flag if the registers have changed since last use.

It might be an AHCI spec violation to change this register once the FIS Receive Engine is active, too, so it might not be too hard of a change; perhaps we can just map the FIS Receive Buffer once the FRE is started.

Did you want to send a patch, or should I?

--js


On Thu, Feb 26, 2015 at 8:45 AM, Stefan Hajnoczi <address@hidden
<mailto:address@hidden>> wrote:

    On Wed, Feb 25, 2015 at 11:13:09PM -0600, Jordan Hargrave wrote:
     > Referencing this old thread:
     >
    https://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg00606.html
     >
     > I've run into an issue recently with testing q35 DMAR/intel iommu
    with ahci
     > driver.  My ahci driver writes the upper-32 bits
    (PORT_FIS_ADDR_HI) first
     > then the lower 32-bits (PORT_FIS_ADDR).
     >
     > The contents of PORT_FIS_ADDR therefore are stale when the
    PORT_FIS_ADDR_HI
     > write calls map_page().  DMAR translation fails at this point as
    the old
     > stale address (from SEABIOS initialization) is not in the DMAR
    page table.

    The AHCI device tries to map on register writes to both the base and
    upper 32-bit registers.  So it should work for a driver that writes
    PORT_FIS_ADDR_HI before PORT_FIS_ADDR.

    Does the iommu failure pose a problem?

    Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]