Re: RFC: extend iommu_ops with domain attributes API

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

 



On Thu, Jan 12, 2012 at 03:47:47PM +0100, Joerg Roedel wrote:
> On Tue, Jan 10, 2012 at 10:22:36AM -0600, Stuart Yoder wrote:
> > A couple of the attributes I'm considering PAMU specific with a generic
> > enable attribute:
> > 
> >    enum iommu_attr_type {
> >        IOMMU_ATTR_PAMU_GEOMETRY,       // the PAMU geometry for the domain
> 
> This should be a generic attribute. It makes sense for nearly all IOMMUs
> to export geometry information.

The type of geometry information expected is not generic, though.

> >        IOMMU_ATTR_ENABLE
> 
> I do not get the need of this one. Can you explain why you need to
> enable/disable a domain? What happens on the hardware side when you do
> that?

When assigning to a KVM guest (or userspace driver) a device that we
can't generically reset or disable bus-mastering, we don't want DMA to go
through until the guest has reset or otherwise quiesced the device, and
told the HV that it's ready for DMA to work.  When we reset the guest, we
stop DMA before reloading the OS image, and again enable it when the
guest driver says it's OK.

While it's possible to accomplish this by only having mappings when it's
OK for DMA to work, this is undesireable because when configuring static
mappings for a guest, we want to know during guest configuration if
the mappings are invalid, rather than at some later point during guest
execution.  PAMU has significant restrictions on what sort of mappings
can be done, especially if we're trying to map a guest's entire memory. 

At the hardware level we can accomplish the enable/disable by flipping a
bit; we'd like for it to be as simple for the IOMMU API user.  Even
ignoring the issue of delayed errors, it's more complicated to have to
remember mappings and reissue them when the guest says OK, and tear them
down on reset.

If this isn't wanted as a generic IOMMU API feature, it could be a
PAMU implementation attribute.

-Scott

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux