lkml.org 
[lkml]   [2022]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 1/3] iommu/s390: Fix duplicate domain attachments
    On Mon, Sep 26, 2022 at 03:29:49PM +0200, Niklas Schnelle wrote:
    > I did miss a problem in my initial answer. While zpci_register_ioat()
    > is indeed the actual "attach" operation, it assumes that at that point
    > no DMA address translations are registered. In that state DMA is
    > blocked of course. With that zpci_register_ioat() needs to come after
    > the zpci_unregister_ioat() that is part of __s390_iommu_detach_device()
    > and zpci_dma_exit_device(). If we do call those though we fundamentally
    > need to restore the previous domain / DMA API state on any subsequent
    > failure. If we don't restore we would leave the device detached from
    > any domain with DMA blocked. I wonder if this could be an acceptable
    > failure state though? It's safe as no DMA is possible and we could get
    > out of it with a successful attach.

    Is this because of that FW call it does?

    It seems like an FW API misdesign to not allow an unfailable change of
    translation, if the FW forces an unregister first then there are
    always error cases you can't correctly recover from.

    IMHO if the FW fails an attach you are just busted, there is no reason
    to think it would suddenly accept attaching the old domain just
    because it has a different physical address, right?

    So make it simple, leave it DMA blocked and throw a WARN_ON..

    Talk to your FW people about fixing the API?

    Jason

    \
     
     \ /
      Last update: 2022-09-26 17:13    [W:3.238 / U:0.156 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site