[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |