From: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> To: "Michael S. Tsirkin" <mst@redhat.com> Cc: joro@8bytes.org, blauwirbel@gmail.com, paul@codesourcery.com, avi@redhat.com, anthony@codemonkey.ws, av1474@comtv.ru, yamahata@valinux.co.jp, kvm@vger.kernel.org, qemu-devel@nongnu.org Subject: Re: [PATCH RFC] dma_rw.h (was Re: [PATCH 0/7] AMD IOMMU emulation patchset v4) Date: Thu, 16 Sep 2010 14:15:25 +0300 [thread overview] Message-ID: <20100916111525.GA7092@localhost> (raw) In-Reply-To: <20100916092043.GB20864@redhat.com> On Thu, Sep 16, 2010 at 11:20:43AM +0200, Michael S. Tsirkin wrote: > On Thu, Sep 16, 2010 at 10:06:16AM +0300, Eduard - Gabriel Munteanu wrote: [snip] > > No, DMADevice is a device that does DMA. > So e.g. a PCI device would embed one. > Remember, traslations are per device, right? > DMAMmu is part of the iommu object. > I agree, all I'm saying is a DMADevice is insufficient to invalidate one of the many maps a given device holds, at least without resorting to horrible tricks or destroying them all. > > so doing this makes it really > > hard to invalidate a specific map when there are more of them. It forces > > device code to act as a bus, provide fake 'DMADevice's for each map and > > dispatch translation to the real DMATranslateFunc. I see no other way. > > > > If you really want more type-safety (although I think this is a case of > > a true opaque identifying something only device code understands), I > > have another proposal: have a DMAMap embedded in the opaque. Example > > from dma-helpers.c: > > > > typedef struct { > > DMADevice *owner; > > [...] > > } DMAMap; > > > > typedef struct { > > [...] > > DMAMap map; > > [...] > > } DMAAIOCB; > > > > /* The callback. */ > > static void dma_bdrv_cancel(DMAMap *map) > > { > > DMAAIOCB *dbs = container_of(map, DMAAIOCB, map); > > > > [...] > > } > > > > The upside is we only need to pass the DMAMap. That can also contain > > details of the actual map in case the device wants to release only the > > relevant range and remap the rest. > > Fine. > Or maybe DMAAIOCB (just make some letters lower case: DMAIocb?). > Everyone will use it anyway, right? No, you misunderstood me. DMAAIOCB is already there in dma-helpers.c, it's the opaque I used and it was already there before my patches. The idea was to define DMAMap and embed it in DMAAIOCB, so we can upcast from the former to the latter (which is what we actually need). IDE DMA uses that, but other devices would use whatever they want, even nothing except the DMAMap. The only requirement is that the container struct allows device code to acknowledge the invalidation (in case of AIO, we simply kill that thread and release resources). Well, perhaps DMAMap isn't the best name, but you get the idea. > > > I saw devices do stl_le_phys and such, these > > > might need to be wrapped as well. > > > > stl_le_phys() is defined and used only by hw/eepro100.c. That's already > > dealt with by converting the device. > > > > I see. Need to get around to adding some prefix to it to make this clear. > > > Thanks, > > Eduard > > [snip] Eduard
WARNING: multiple messages have this Message-ID (diff)
From: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> To: "Michael S. Tsirkin" <mst@redhat.com> Cc: kvm@vger.kernel.org, joro@8bytes.org, qemu-devel@nongnu.org, blauwirbel@gmail.com, yamahata@valinux.co.jp, paul@codesourcery.com, avi@redhat.com Subject: [Qemu-devel] Re: [PATCH RFC] dma_rw.h (was Re: [PATCH 0/7] AMD IOMMU emulation patchset v4) Date: Thu, 16 Sep 2010 14:15:25 +0300 [thread overview] Message-ID: <20100916111525.GA7092@localhost> (raw) In-Reply-To: <20100916092043.GB20864@redhat.com> On Thu, Sep 16, 2010 at 11:20:43AM +0200, Michael S. Tsirkin wrote: > On Thu, Sep 16, 2010 at 10:06:16AM +0300, Eduard - Gabriel Munteanu wrote: [snip] > > No, DMADevice is a device that does DMA. > So e.g. a PCI device would embed one. > Remember, traslations are per device, right? > DMAMmu is part of the iommu object. > I agree, all I'm saying is a DMADevice is insufficient to invalidate one of the many maps a given device holds, at least without resorting to horrible tricks or destroying them all. > > so doing this makes it really > > hard to invalidate a specific map when there are more of them. It forces > > device code to act as a bus, provide fake 'DMADevice's for each map and > > dispatch translation to the real DMATranslateFunc. I see no other way. > > > > If you really want more type-safety (although I think this is a case of > > a true opaque identifying something only device code understands), I > > have another proposal: have a DMAMap embedded in the opaque. Example > > from dma-helpers.c: > > > > typedef struct { > > DMADevice *owner; > > [...] > > } DMAMap; > > > > typedef struct { > > [...] > > DMAMap map; > > [...] > > } DMAAIOCB; > > > > /* The callback. */ > > static void dma_bdrv_cancel(DMAMap *map) > > { > > DMAAIOCB *dbs = container_of(map, DMAAIOCB, map); > > > > [...] > > } > > > > The upside is we only need to pass the DMAMap. That can also contain > > details of the actual map in case the device wants to release only the > > relevant range and remap the rest. > > Fine. > Or maybe DMAAIOCB (just make some letters lower case: DMAIocb?). > Everyone will use it anyway, right? No, you misunderstood me. DMAAIOCB is already there in dma-helpers.c, it's the opaque I used and it was already there before my patches. The idea was to define DMAMap and embed it in DMAAIOCB, so we can upcast from the former to the latter (which is what we actually need). IDE DMA uses that, but other devices would use whatever they want, even nothing except the DMAMap. The only requirement is that the container struct allows device code to acknowledge the invalidation (in case of AIO, we simply kill that thread and release resources). Well, perhaps DMAMap isn't the best name, but you get the idea. > > > I saw devices do stl_le_phys and such, these > > > might need to be wrapped as well. > > > > stl_le_phys() is defined and used only by hw/eepro100.c. That's already > > dealt with by converting the device. > > > > I see. Need to get around to adding some prefix to it to make this clear. > > > Thanks, > > Eduard > > [snip] Eduard
next prev parent reply other threads:[~2010-09-16 11:17 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-08-28 14:54 [PATCH 0/7] AMD IOMMU emulation patchset v4 Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [PATCH 1/7] pci: expand tabs to spaces in pci_regs.h Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-08-31 20:29 ` Michael S. Tsirkin 2010-08-31 20:29 ` [Qemu-devel] " Michael S. Tsirkin 2010-08-31 22:58 ` Eduard - Gabriel Munteanu 2010-08-31 22:58 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-09-01 10:39 ` Michael S. Tsirkin 2010-09-01 10:39 ` [Qemu-devel] " Michael S. Tsirkin 2010-08-28 14:54 ` [PATCH 2/7] pci: memory access API and IOMMU support Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-09-02 5:28 ` Michael S. Tsirkin 2010-09-02 5:28 ` [Qemu-devel] " Michael S. Tsirkin 2010-09-02 8:40 ` Eduard - Gabriel Munteanu 2010-09-02 8:40 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-09-02 9:49 ` Michael S. Tsirkin 2010-09-02 9:49 ` [Qemu-devel] " Michael S. Tsirkin 2010-09-04 9:01 ` Blue Swirl 2010-09-04 9:01 ` [Qemu-devel] " Blue Swirl 2010-09-05 7:10 ` Michael S. Tsirkin 2010-09-05 7:10 ` [Qemu-devel] " Michael S. Tsirkin 2010-08-28 14:54 ` [PATCH 3/7] AMD IOMMU emulation Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-08-28 15:58 ` Blue Swirl 2010-08-28 15:58 ` [Qemu-devel] " Blue Swirl 2010-08-28 21:53 ` Eduard - Gabriel Munteanu 2010-08-28 21:53 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-08-29 20:37 ` Blue Swirl 2010-08-29 20:37 ` [Qemu-devel] " Blue Swirl 2010-08-30 3:07 ` [Qemu-devel] " Isaku Yamahata 2010-08-30 3:07 ` Isaku Yamahata 2010-08-30 5:54 ` Eduard - Gabriel Munteanu 2010-08-30 5:54 ` Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [PATCH 4/7] ide: use the PCI memory access interface Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-09-02 5:19 ` Michael S. Tsirkin 2010-09-02 5:19 ` [Qemu-devel] " Michael S. Tsirkin 2010-09-02 9:12 ` Eduard - Gabriel Munteanu 2010-09-02 9:12 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-09-02 9:58 ` Michael S. Tsirkin 2010-09-02 9:58 ` [Qemu-devel] " Michael S. Tsirkin 2010-09-02 15:01 ` Eduard - Gabriel Munteanu 2010-09-02 15:01 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-09-02 15:24 ` Avi Kivity 2010-09-02 15:24 ` [Qemu-devel] " Avi Kivity 2010-09-02 15:39 ` Michael S. Tsirkin 2010-09-02 15:39 ` [Qemu-devel] " Michael S. Tsirkin 2010-09-02 16:07 ` Avi Kivity 2010-09-02 16:07 ` [Qemu-devel] " Avi Kivity 2010-09-02 15:31 ` Michael S. Tsirkin 2010-09-02 15:31 ` [Qemu-devel] " Michael S. Tsirkin 2010-08-28 14:54 ` [PATCH 5/7] rtl8139: " Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [PATCH 6/7] eepro100: " Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [PATCH 7/7] ac97: " Eduard - Gabriel Munteanu 2010-08-28 14:54 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-08-28 16:00 ` [PATCH 0/7] AMD IOMMU emulation patchset v4 Blue Swirl 2010-08-28 16:00 ` [Qemu-devel] " Blue Swirl 2010-08-29 9:55 ` Joerg Roedel 2010-08-29 9:55 ` [Qemu-devel] " Joerg Roedel 2010-08-29 20:44 ` Blue Swirl 2010-08-29 20:44 ` [Qemu-devel] " Blue Swirl 2010-08-29 22:08 ` [PATCH 2/7] pci: memory access API and IOMMU support Eduard - Gabriel Munteanu 2010-08-29 22:08 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-08-29 22:11 ` Eduard - Gabriel Munteanu 2010-08-29 22:11 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-09-01 20:10 ` [Qemu-devel] " Stefan Weil 2010-09-01 20:10 ` Stefan Weil 2010-09-02 6:00 ` Michael S. Tsirkin 2010-09-02 6:00 ` Michael S. Tsirkin 2010-09-02 9:08 ` Eduard - Gabriel Munteanu 2010-09-02 9:08 ` Eduard - Gabriel Munteanu 2010-09-02 13:24 ` Anthony Liguori 2010-09-02 13:24 ` Anthony Liguori 2010-09-02 8:51 ` Eduard - Gabriel Munteanu 2010-09-02 8:51 ` Eduard - Gabriel Munteanu 2010-09-02 16:05 ` Stefan Weil 2010-09-02 16:05 ` Stefan Weil 2010-09-02 16:14 ` Eduard - Gabriel Munteanu 2010-09-02 16:14 ` Eduard - Gabriel Munteanu 2010-09-13 20:01 ` [PATCH RFC] dma_rw.h (was Re: [PATCH 0/7] AMD IOMMU emulation patchset v4) Michael S. Tsirkin 2010-09-13 20:01 ` [Qemu-devel] " Michael S. Tsirkin 2010-09-13 20:45 ` Anthony Liguori 2010-09-13 20:45 ` Anthony Liguori 2010-09-16 7:12 ` Eduard - Gabriel Munteanu 2010-09-16 7:12 ` Eduard - Gabriel Munteanu 2010-09-16 9:35 ` Michael S. Tsirkin 2010-09-16 9:35 ` Michael S. Tsirkin 2010-09-16 7:06 ` Eduard - Gabriel Munteanu 2010-09-16 7:06 ` [Qemu-devel] " Eduard - Gabriel Munteanu 2010-09-16 9:20 ` Michael S. Tsirkin 2010-09-16 9:20 ` [Qemu-devel] " Michael S. Tsirkin 2010-09-16 11:15 ` Eduard - Gabriel Munteanu [this message] 2010-09-16 11:15 ` Eduard - Gabriel Munteanu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20100916111525.GA7092@localhost \ --to=eduard.munteanu@linux360.ro \ --cc=anthony@codemonkey.ws \ --cc=av1474@comtv.ru \ --cc=avi@redhat.com \ --cc=blauwirbel@gmail.com \ --cc=joro@8bytes.org \ --cc=kvm@vger.kernel.org \ --cc=mst@redhat.com \ --cc=paul@codesourcery.com \ --cc=qemu-devel@nongnu.org \ --cc=yamahata@valinux.co.jp \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.