Re: [Xen-devel] [PATCH 1/3] iommu: set correct IOMMU entries when iommu_hap_pt_share == 0

[Tim Deegan <tim@xxxxxxx>]

At 17:15 +0200 on 08 Apr (1396973715), Roger Pau Monné wrote:
> On 08/04/14 16:12, Tim Deegan wrote:
> > At 09:30 +0100 on 08 Apr (1396945844), Jan Beulich wrote:
> >>>>> On 07.04.14 at 18:02, <roger.pau@xxxxxxxxxx> wrote:
> >>> If the memory map is not shared between HAP and IOMMU we fails to set
> >>> correct IOMMU mappings for memory types different than p2m_ram_rw.
> >>>
> >>> This patchs adds IOMMU support for the following memory types:
> >>> p2m_grant_map_rw, p2m_map_foreign, p2m_ram_ro and p2m_grant_map_ro.
> >>
> >> I'm curious about the justification for p2m_map_foreign; the others
> >> I agree with.
> >>
> >> I also wonder whether p2m_ram_logdirty shouldn't be treated
> >> equally to p2m_ram_rw: It's clearly better to have some video
> >> corruption than to kill the guest due to excessive IOMMU faults,
> > 
> > Hmmm.  In that case it seems better; if we're absolutely sure that we
> > can't end up trying to do log-dirty for _migration_ while a guest has
> > a real device passed through, then yes, we can leave them as r/w to
> > the IOMMU. 
> > 
> > Maybe make sure at the same time that full log-dirty mode and
> > needs_iommu are mutually exclusive.
> 
> Would it suffice to add something like:
> 
> case p2m_ram_logdirty:
>     ASSERT(!paging_mode_log_dirty(p2m->domain));
> 
> Or are you referring to a more global check?

I was thinking that the paths that _set_ full log-dirty mode or
needs_iommu should explicitly test that the other isn't the case
(i.e. a logdirty-enable hypercall or assigning a passthough device
should fail).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel