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

Re: [Xen-devel] [PATCH v2] x86/p2m-pt: tighten conditions of IOMMU mapping updates



On Fri, Oct 2, 2015 at 8:31 AM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>> George Dunlap <george.dunlap@xxxxxxxxxx> 10/01/15 6:16 PM >>>
>>On 01/10/15 11:25, Jan Beulich wrote:
>>> TBD: As already mentioned on the large-page-MMIO-mapping patch, there
>>>      is an apparent inconsistency with PoD handling: 2M mappings get
>>>      valid entries created, while 4k mappings don't. It would seem to
>>>      me that the 4k case needs changing, even if today this may only
>>>      be a latent bug. Question of course is why we don't rely on
>>>      p2m_type_to_flags() doing its job properly and instead special
>>>      case certain P2M types.
>>
>>The inconsistency in the conditionals there is a bit strange; but I'm
>>pretty sure that in the 2MB case it is (at the moment) superfluous,
>>because at the moment it seems that when setting a page with type
>>p2m_populate_on_demand, it's always passing in _mfn(0), which is valid.
>>
>>(It used to pass a magic MFN, but Tim Deegan switched it to _mfn(0) at
>>some point without comment.)
>
> Perhaps just because the magic MFN didn't always work? Tim?
> To me it looks wrong to pass anything other than INVALID_MFN
> there.

Well the magic MFN was also a valid MFN (it was like 1<<9 or
something), which is probably worse than _mfn(0). :-)

If we change it to INVALID_MFN, we'd have to either add exceptions in
all of those conditionals (so it doesn't get l1e_empty()), or perhaps
(as you say) trust p2m_type_to_flags() to DTRT.  The second is
probably the best option, but obviously not at this stage in the
release.

 -George

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.