Re: [Xen-devel] Live migration with MMIO pages

[Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>]

At 11:18 +0000 on 01 Nov (1193915902), Kieran Mansley wrote:
> I'm a bit concerned about this one in _sh_propogate().  It seems it's
> checking that the mfn is valid for a good reason, and so letting it
> carry on in the case of MMIO frames will lead to a rather ungraceful
> failure.  If I modify the above if to be:
>
>     if ( !mfn_valid(target_mfn) && (p2mt != p2m_mmio_direct) 
>          && !iomem_access_permitted(d, target_mfn, target_mfn))
> 
> so that PV iomem frames can continue rather than giving up at this
> point, it gets a fatal page fault (see below).

Oh dear.  Yes, you'll need to protect all the stuff further down that
tries to mark the frame dirty.  Probably making sh_mfn_is_dirty test for
!mfn_valid(mfn) and return 0 will be enough.

> I wonder if the comment above that if has the answer:
> 
>     /* N.B. For pass-through MMIO, either this test needs to be relaxed,
>      * and shadow_set_l1e() trained to handle non-valid MFNs (ugh), or
> the
>      * MMIO areas need to be added to the frame-table to make them
> "valid". */

That comment is gone in -unstable, since the IOMMU pass-through to HVM
domains went in.  Passing through the MMIO mappings should work because
get_page_from_l1e will do the right thing later.

Another thing to worry about in _sh_propagate is that the shadows don't
retain any of the caching attribute bits from the guest entries.  You
might want to add _PAGE_PCD and _PAGE_PWT to "pass_thru_flags" for PV
guests (and for l1es, _PAGE_PAT, I suppose, if PV guests are allowed to
use PAT).

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Principal Software Engineer, Citrix Systems.
[Company #5334508: XenSource UK Ltd, reg'd c/o EC2Y 5EB, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel