qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] RFC: vfio API changes needed for powerpc


From: Scott Wood
Subject: Re: [Qemu-devel] RFC: vfio API changes needed for powerpc
Date: Tue, 2 Apr 2013 16:55:34 -0500

On 04/02/2013 04:08:27 PM, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood <address@hidden> wrote:
>> This could also be done as another "type2" ioctl extension.
>
>
> Again, what is "type2", specifically? If someone else is adding their own > IOMMU that is kind of, sort of like PAMU, how would they know if it's close > enough? What assumptions can a user make when they see that they're dealing
> with "type2"?

We will define that as part of the type2 implementation. Highly unlikely
anything but a PAMU will comply.

So then why not just call it "pamu" instead of being obfuscatory?

> There's going to be special stuff no matter what. This would keep it
> separated from the IOMMU map code.
>
> I'm not sure what you mean by "overhead" here... the runtime overhead of > setting things up is not particularly relevant as long as it's reasonable.
> If you mean development and maintenance effort, keeping things well
> separated should help.

We don't need to change DMA_MAP.  If we can simply add a new "type 2"
ioctl that allows user space to set which windows are MSIs,

And what specifically does that ioctl do? It causes new mappings to be created, right? So you're changing (or at least adding to) the DMA map mechanism.

it seems vastly less complex than an ioctl to supply a new fd, mmap of it, etc.

I don't see enough complexity in the mmap approach for anything to be "vastly less complex" in comparison. I think you're building the mmap approach up in your head to be a lot worse that it would actually be.

-Scott



reply via email to

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