All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/3] iommu: set correct IOMMU entries when iommu_hap_pt_share == 0
Date: Tue, 8 Apr 2014 17:15:15 +0200	[thread overview]
Message-ID: <53441283.4060305@citrix.com> (raw)
In-Reply-To: <20140408141245.GB27003@deinos.phlegethon.org>

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@citrix.com> 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?

Thanks, Roger.

  reply	other threads:[~2014-04-08 15:16 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-07 16:02 [PATCH 0/3] Fix grant map/unmap with auto-translated guests Roger Pau Monne
2014-04-07 16:02 ` [PATCH 1/3] iommu: set correct IOMMU entries when iommu_hap_pt_share == 0 Roger Pau Monne
2014-04-07 16:49   ` Konrad Rzeszutek Wilk
2014-04-08  8:30   ` Jan Beulich
2014-04-08  9:19     ` Roger Pau Monné
2014-04-08  9:55       ` Jan Beulich
2014-04-08 14:12     ` Tim Deegan
2014-04-08 15:15       ` Roger Pau Monné [this message]
2014-04-08 15:29         ` Jan Beulich
2014-04-13 20:27         ` Tim Deegan
2014-04-16 14:36     ` Roger Pau Monné
2014-04-16 14:41       ` Jan Beulich
2014-04-07 16:02 ` [PATCH 2/3] amd-iommu: disable iommu_hap_pt_share with AMD IOMMUs Roger Pau Monne
2014-04-07 16:51   ` Konrad Rzeszutek Wilk
2014-04-07 16:54     ` George Dunlap
2014-04-08  7:29       ` Roger Pau Monné
2014-04-08  8:52   ` Jan Beulich
2014-04-08 14:16     ` Tim Deegan
2014-04-08 14:36       ` Jan Beulich
2014-04-08 15:39     ` Roger Pau Monné
2014-04-07 16:02 ` [PATCH 3/3] xen: expose that grant table mappings update the IOMMU Roger Pau Monne
2014-04-08  8:34   ` Ian Campbell
2014-04-08  8:56     ` Jan Beulich
2014-04-08  8:58       ` Ian Campbell
2014-04-08  9:53         ` Jan Beulich
2014-04-08  9:57           ` Ian Campbell
2014-04-08 10:05             ` Jan Beulich
2014-04-08 10:26               ` Ian Campbell
2014-04-08 10:31                 ` Jan Beulich

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=53441283.4060305@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.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 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.