[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
> 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. Andres > > Tim. > > > > ------------------------------ > > Message: 7 > Date: Thu, 24 Nov 2011 11:38:19 +0000 > From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> > To: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx> > Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx> > Subject: Re: [Xen-devel] [PATCH 00 of 14] MM Fixes > Message-ID: <20174.11435.306730.583922@xxxxxxxxxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset="us-ascii" > > Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 00 of 14] MM Fixes"): >> This patch series includes a number of bug fixes, targetting >> primarily the mm layer. Many of these fixes also lay groundwork >> for future patches. > > Thanks. Something seems to have eaten patches 12,13,14. > > Can you please confirm that you sent them, and tell me their > messageids, and any information you can tell me about their > transmission ? > > Ideally I would like log entries from the final hop mail server on > your side showing the messages being handed over to the MX's for > lists.xensource.com, but looking at the headers of your other messages > they came through "homiemail-***.***.dreamhost.com" so that may > involve talking to whoever they are. > > Thanks, > Ian. > > > > ------------------------------ > > Message: 8 > Date: Thu, 24 Nov 2011 11:58:16 +0000 > From: Tim Deegan <tim@xxxxxxx> > To: ???? <327801865@xxxxxx> > Cc: Xen-devel <Xen-devel@xxxxxxxxxxxxxxxxxxx> > Subject: Re: [Xen-devel] HVM (hypercall_grant_table_op) Problem > Message-ID: <20111124115816.GD77868@xxxxxxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset=iso-8859-1 > > Hi, > > At 00:52 +0800 on 18 Nov (1321577533), ???? wrote: >> Hi: >> I modified the netfont.c of Linux HVM domU installed PVonHVM.In it, >> I call hypercall_grant_table_op >> (GNTTABOP_map_grant_ref...), then dom0 shutdown and restart at once. > > Do you have a serial line attached to the machine to capture the console > output when this happens? Without that it's hard to knwo what the bug is. > >> From above, I conclude that I can map a HVM's page to another HVM, >> just like two PVs. >> Am I wrong? Who can give me some suggestion? > > Yes, HVM guests can now map granted frames, but not quite 'just like pv'. > The grant hypercall maps the granted frame into the HVM guest's p2m map, > instead of into the pagetables. That is, you pass in a PFN, and when > the grant succeeds, you still need to map that PFN in your pagetables to > access the page. > > The checkin that added the feature came with this comment: > > After some discussion, here's a second version of the patch I posted a > couple of weeks back to map grant references into HVM guests. As > before, this is done by modifying the P2M map, but this time there's > no new hypercall to do it. Instead, the existing GNTTABOP_map is > overloaded to perform a P2M mapping if called from a shadow mode > translate guest. This matches the IA64 API. > > http://xenbits.xen.org/hg/xen-unstable.hg/rev/c0cb307d927f > > Tim. > > > > ------------------------------ > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > > > End of Xen-devel Digest, Vol 81, Issue 328 > ****************************************** > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |