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

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

> 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