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
|
Home