Re: monitor access to pages with a specific p2m_type_t

[sepanta s <sapanta992@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6143 bytes --]

On Fri, Aug 5, 2016 at 10:45 PM, Tamas K Lengyel <tamas@tklengyel.com>
wrote:

>
>
> On Fri, Aug 5, 2016 at 5:35 AM, sepanta s <sapanta992@gmail.com> wrote:
>
>>
>>
>> On Tue, Aug 2, 2016 at 8:23 PM, Tamas K Lengyel <tamas@tklengyel.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Aug 2, 2016 at 12:19 AM, sepanta s <sapanta992@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Jul 23, 2016 at 3:49 PM, sepanta s <sapanta992@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>>> 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.
>>>>>>
>>>>>
>>>>> There was a function in mem-sharing.c which is intended to announce
>>>>> the failed unshared pages. It is "mem_sharing_notify_enomem" .
>>>>> I added "mem_sharing_notify_unshare" as a new function and call it in
>>>>> also XEN_DOMCTL_VM_EVENT_OP_UNSHARING and "HVM_PARAM_USHARING_RING_PFN".
>>>>> I also added the required codes in /xen/common/vm_event.c and
>>>>> /tools/libxc/xc_vm_event so as
>>>>> I have added a new event for the unsharing actions of a page.
>>>>> Then, I wrote a sample code line xen-access and create a ring for the
>>>>> pages of a domain and listen to unshared events of it.
>>>>>
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>> You are right, xen-access should work but I couldn't change its code
>>>>> and couldn't get the mem-access events.
>>>>>  I just added the above function to be sure that unsharing a page
>>>>> happens and works fine. Because I couldn't get the access requests on
>>>>> shared-pages of a vm.
>>>>> In xen-access, Instead of setting all the pages' default access to rx
>>>>> , I just call xc_set_mem_access for the pages with p2m_ram_shared and
>>>>> assign rx as the default access but there is no requests on this 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.
>>>>>>
>>>>> Yes it was crashed as I checked it.
>>>>> The scenario of sharing is I use:
>>>>> I pause the origin VM and then run memshrtool on origin VM and clone
>>>>> VM. After sharing all the pages between these two VMs,Clone VM seems to be
>>>>> inaccessible. The clone seems to work as the attached photo shows, its cpu
>>>>> time increases and it exceeds the dom0 cpu time but when I use gvncviewer
>>>>> to see the GUI of the Clone VM, the mouse or keyboard don't work. (origin
>>>>> VM is ubunut-64-1 and clone VM is ubuntu-64-clone-1). Is there anything I
>>>>> have missed in sharing between two VMs?
>>>>>
>>>>> [image: Inline image 2]
>>>>>
>>>>
>>>> Can someone help please ? still have problem with the machine .
>>>> is it because sharing is not based on content?
>>>>
>>>>
>>> Well, the emulated device contexts probably get all messed up when you
>>> just clone over the memory of the domain and that's why they don't work.
>>> The only way I got this to work is by doing a save/restore of the origin
>>> domain before doing the memory sharing.
>>>
>>> Tamas
>>>
>> I do so , as I use the following commands to create the clone :
>> xl save -c origin-domid /tmp/clone
>> xl restore -p -e  /etc/xen/clone.config  /tmp/clone
>> Also I keep the origin and clone both unpaused before sharing and after
>> that, I just unpause the clone , but I
>> can just run some commands and then the clone stops responding to mouse
>> operations.
>> My vms are both ubuntu-14.04 LTS.
>>
>
> I guess you mean you keep both of them paused before sharing, and after
> sharing you only unpause the clone.
>

yes, that's true. What is the correct procedure for sharing two machines?


> I'm not sure xl save -c will keep the domain paused after it is saved
> though.
>
No it doesn't, so as I use xl save -p


> Also, in my experience you have to restore _both_ the origin and the clone
> domain from a save state for this to work flawlessly.
>


> Underlying reason for this is unknown, I haven't investigated further into
> it after finding at least one way to get it working.
>
> Tamas
>

[-- Attachment #1.2: Type: text/html, Size: 13509 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel