Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only

[Tim Deegan <tim@xxxxxxx>]

At 09:09 -0800 on 24 Nov (1322125786), Andres Lagar-Cavilla wrote:
> > Date: Thu, 24 Nov 2011 11:38:02 +0000
> > From: Tim Deegan <tim@xxxxxxx>
> > To: Olaf Hering <olaf@xxxxxxxxx>
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state
> >     read-only
> > Message-ID: <20111124113802.GB77868@xxxxxxxxxxxxxxxxxxxxx>
> > Content-Type: text/plain; charset=iso-8859-1
> >
> > At 17:53 +0100 on 14 Nov (1321293182), Olaf Hering wrote:
> >>
> >> I was wondering why ept_p2m_type_to_flags() removes all permissions from
> >> a gfn in state p2m_ram_paging_out. If the guest happens to read or
> >> execute from that page while the pager writes that gfn to disk, wouldnt
> >> it be enough to remove the write bit to prevent writes from the guest?
> >> If the page is read-only the guest could continue to make progress until
> >> the gfn is really evicted and the p2mt changes to p2m_ram_paged.
> >>
> >> I havent actually tried the patch below, but is there any reason it
> >> would break the guest?
> >
> > As long as we change the p2m type before scrubbing or freeing the page,
> > that seems like it shuold be fine.
> 
> Is this a good idea? If the guest is accessing the page, then paging out
> should stop immediately. We're risking complex races for a tiny tiny gain.

I don't think that this would introduce any new races, but yes - this is
probably a hint that this page is a poor candidate to be paged out.
We might as well abandon the page-out rather than probably having to
page it back in immediately.

Tim.

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