From: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: joro@8bytes.org, kvm@vger.kernel.org, qemu-devel@nongnu.org,
avi@redhat.com, paul@codesourcery.com
Subject: Re: [Qemu-devel] [RFC PATCH 1/4] pci: memory access API and IOMMU support
Date: Fri, 6 Aug 2010 03:21:28 +0300 [thread overview]
Message-ID: <20100806002128.GA19250@localhost> (raw)
In-Reply-To: <AANLkTikVxM2QvXa23-x3Q0ZaQ83qTDMvjKEbVNzgSRKs@mail.gmail.com>
On Thu, Aug 05, 2010 at 09:23:30PM +0000, Blue Swirl wrote:
> On Wed, Aug 4, 2010 at 10:32 PM, Eduard - Gabriel Munteanu
[snip]
> > @@ -58,6 +58,10 @@ struct PCIBus {
> > ?? ?? ?? ??Keep a count of the number of devices with raised IRQs. ??*/
> > ?? ?? int nirq;
> > ?? ?? int *irq_count;
> > +
> > +#ifdef CONFIG_PCI_IOMMU
>
> The code should not be conditional.
>
> > + ?? ??PCIIOMMU *iommu;
> > +#endif
> > ??};
> >
> > ??static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
> > @@ -2029,6 +2033,147 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> > ?? ?? }
> > ??}
> >
> > +#ifdef CONFIG_PCI_IOMMU
> > +
> > +void pci_register_iommu(PCIDevice *dev, PCIIOMMU *iommu)
> > +{
> > + ?? ??dev->bus->iommu = iommu;
> > +}
> > +
> > +void pci_memory_rw(PCIDevice *dev,
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? pci_addr_t addr,
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? uint8_t *buf,
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? pci_addr_t len,
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? int is_write)
> > +{
> > + ?? ??int err, plen;
> > + ?? ??unsigned perms;
> > + ?? ??PCIIOMMU *iommu = dev->bus->iommu;
> > + ?? ??target_phys_addr_t paddr;
> > +
> > + ?? ??if (!iommu || !iommu->translate)
> > + ?? ?? ?? ??return cpu_physical_memory_rw(addr, buf, len, is_write);
>
> Instead of these kind of checks, please add default handlers which
> call cpu_physical_memory_rw() etc.
>
Ok. I'm trying to minimize impact (non-inlineable function calls) when
the IOMMU is disabled at compile-time. I think I can do it some other
way, as you suggest.
> > +
> > + ?? ??perms = is_write ? IOMMU_PERM_WRITE : IOMMU_PERM_READ;
>
> Is this useful? How about just passing is_write as perms?
>
Only in theory: it might come in handy if we ever support RW operations,
like read-modify-write memory maps. Also, write permissions include
zero-byte reads for the AMD IOMMU, so IOMMU_PERM_* could be further
refined.
I'm happy to remove it, though.
[snip]
> > +/*
> > + * Memory I/O and PCI IOMMU definitions.
> > + */
> > +
> > +typedef target_phys_addr_t pci_addr_t;
>
> There is already pcibus_t.
>
Thanks, I'll use that.
> > +
> > +typedef int PCIInvalidateIOTLBFunc(void *opaque);
>
> I think some type safety tricks could be used with for example PCIDevice *.
>
Note that 'opaque' belongs to the caller (the code that requests
memory maps).
Some device might make multiple maps that can be invalidated separately.
The actual stuff that describes the map might not be straightforward to
recover from a PCIDevice.
We could add another parameter to PCIInvalidateIOTLBFunc(), but since
the main user is DMA code, it's going to complicate things further.
[snip]
Eduard
next prev parent reply other threads:[~2010-08-06 0:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-04 22:32 [RFC PATCH 0/4] AMD IOMMU emulation 2nd version Eduard - Gabriel Munteanu
2010-08-04 22:32 ` [RFC PATCH 1/4] pci: memory access API and IOMMU support Eduard - Gabriel Munteanu
2010-08-05 21:23 ` [Qemu-devel] " Blue Swirl
2010-08-06 0:21 ` Eduard - Gabriel Munteanu [this message]
2010-08-04 22:32 ` [RFC PATCH 2/4] AMD IOMMU emulation Eduard - Gabriel Munteanu
2010-08-05 21:31 ` [Qemu-devel] " Blue Swirl
2010-08-06 0:41 ` Eduard - Gabriel Munteanu
2010-08-04 22:32 ` [RFC PATCH 3/4] ide: use the PCI memory access interface Eduard - Gabriel Munteanu
2010-08-04 22:32 ` [RFC PATCH 4/4] rtl8139: " Eduard - Gabriel Munteanu
2010-08-05 21:13 ` [Qemu-devel] [RFC PATCH 0/4] AMD IOMMU emulation 2nd version Blue Swirl
2010-08-06 14:09 ` Question about starting 2 VMs using Qemu Anjali Kulkarni
2010-08-07 17:43 ` Question about e1000 NIC emulation in Qemu - chipset used Anjali Kulkarni
2010-08-09 1:49 ` Question about starting 2 VMs using Qemu haishan
2010-08-09 22:18 ` Nirmal Guhan
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=20100806002128.GA19250@localhost \
--to=eduard.munteanu@linux360.ro \
--cc=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox