Re: [Xen-devel] bogus gfn - mfn - gfn - mfn checks in guest_physmap_add_entry

[Patrick Colp <pjcolp@xxxxxxxxx>]

On 24 November 2010 11:58, Olaf Hering <olaf@xxxxxxxxx> wrote:
> On Wed, Nov 24, Olaf Hering wrote:
>
>> On Wed, Nov 24, Tim Deegan wrote:
>
>> > Another option would be to audit all callers of p2m_is_ram() and check
>> > whether they can handle paged-out PFNs (which I though had already been
>> > done but seems not to be).  Keir's VCPU yield patch might be useful in
>> > some of those places too.
>>
>> I think most if not all is caught by my changes already.
>
> A quick grep shows there are a few places that need an audit wether or
> not the paging types can be removed from p2m_is_ram().

If I recall correctly, I made the paging types part of p2m_is_ram()
because the idea was to have paged out pages appear to be normal
pages. But I think this was done without deep analysis of other bits
of the Xen code that might be confused (and as to whether it would
make Xen explode if they weren't part of p2m_is_ram()). But there
could be places that do a check against p2m_is_ram() where a paged out
page should be returning true. I'm sure those calls can be tracked
down and an extra check added for paged out pages too.

Doing a quick scan, it seems like there are some places that checks
against p2m_is_ram() will have to be update, some where having paged
types might be an issue, and others where above it is a check to
p2m_is_paging(), so it should be fine if paging types aren't ram
types. It doesn't seem like there's too many places to check, though,
so hopefully it's not too horrible to fix this up.


Patrick

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