On Mon, Jul 11, 2016 at 6:25 AM, sepanta s <sapanta...@gmail.com> wrote:
>
>
> On Sun, Jul 10, 2016 at 4:50 PM, sepanta s <sapanta...@gmail.com> wrote:
>
>>
>>
>> On Sun, Jun 26, 2016 at 5:15 PM, sepanta s <sapanta...@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Fri, Jun 24, 2016 at 8:10 PM, Tamas K Lengyel <ta...@tklengyel.com>
>>> wrote:
>>>
>>>>
>>>> On Jun 24, 2016 05:19, "Razvan Cojocaru" <rcojoc...@bitdefender.com>
>>>> wrote:
>>>> >
>>>> > On 06/24/2016 02:05 PM, George Dunlap wrote:
>>>> > > On Wed, Jun 22, 2016 at 12:38 PM, sepanta s <sapanta...@gmail.com>
>>>> wrote:
>>>> > >> Hi,
>>>> > >> Is it possible to monitor the access on the pages withp2m_type_t
>>>> > >> p2m_ram_shared?
>>>> > >
>>>> > > cc'ing Tamas and Razvan
>>>> >
>>>> > Thanks for the CC. Judging by the "if ( npfec.write_access && (p2mt ==
>>>> > p2m_ram_shared) )" line in hvm_hap_nested_page_fault() (from
>>>> > xen/arch/x86/hvm/hvm.c), I'd say it certainly looks possible. But I
>>>> > don't know what the context of the question is.
>>>> >
>>>> >
>>>> > Thanks,
>>>> > Razvan
>>>>
>>> The question is just getting the gfn and mfn of the page which is as
>>> type: p2m_ram_shared to see which pages are written and unshared.
>>>
>>>> Yes, p2m_ram_shared type pages can be monitored with mem_access just as
>>>> normal pages. The only part that may be tricky is if you map the page into
>>>> your monitoring application while the page is shared. Your handle will
>>>> continue to be valid even if the page is unshared but it will continue to
>>>> point to the shared page. However, even if you catch write access events to
>>>> the shared page that will lead to unsharing, the mem_access notification is
>>>> sent before unsharing. I just usually do unsharing myself in the mem_access
>>>> callback manually for monitored pages for this reason. I might change the
>>>> flow in 4.8 to send the notification after the unsharing happened to
>>>> simplify this.
>>>>
>>>> Tamas
>>>>
>>> Thanks, but in mem_access , what APIs can be used to see such events ?
>>>
>>
>> Should I mark the shared pages as rx only ?
>>
>>
> Hi,
> Is there any sample code which I can undestand how to capture the events
> on the gfns which have p2m_ram_shared enabled ?
> I couldn't find any ... .
> I would be grateful if any help , as there is not any documents through
> net to use :(
>
>
Should I just set the ring_page as the pages which are shared and mark them
> read-only, then capture the write events?
>
Not sure what ring_page you are talking about, but if you mark the pages
read-only with mem_access you will get notifications for events that lead
to unsharing with p2m_ram_shared type pages as well.
>
> BTW, I added a function called mem_sharing_notify_unshare to
> mem_sharing.c and added it to __mem_sharing_unshare_page at this part:
>
> *if ( p2m_change_type_one(d, gfn, p2m_ram_shared, p2m_ram_rw) )*
> *{*
> *gdprintk(XENLOG_ERR, "Could not change p2m type d %hu gfn %lx.\n", *
> *d->domain_id, gfn);*
> *BUG();*
> *}else {*
>
>
> * mem_sharing_notify_unshare(d,gfn.0);*
> *}*
>
>
IMHO this duplicates a lot of what mem_access does already, I don't think
there is a need for a separate notification on another ring.
> So by having a vm event channel listening to unsharing event, I can see
> the notification in xen-access . To do so, I
> have used vm_event_enable which uses HVM_PARAM_SHARING_RING_PFN .
> But, when I used memshrtool to share all the pages of two vms - my vm1 and
> its clone vm2 .
> About 900 MB of the ram is shared but there are a lot of unshared events
> happening.
>
Yes, I would say that's expected.
> When I do the sharing one more time, there is not any pages unshared as
> the total number of shared pages stay the same.
>
Well, if you let the domain run for a while after sharing, then you do the
sharing like that again you are likely going to crash the VM.
> Seems no unsharing is done as the number of shared pages are the same.
> Does any page fault triggers when a write operation is done on a shared
> page among two vms ?
>
I would guess the the VM crashed and that's why you don't see any more
unsharing at that point.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
