[Barrelfish-users] Maybe a Bug of modify_flags

[Shi Jinghao]

Hi Simon,

Yes, according to the output, it works correctly on X86_64. But do you have
any insights about why it would fail on X86_32? Here is my output here with
arch x86_32 on qemu.

pmaptest.0: begin monothelic_frame test...
kernel 0: user page fault in 'pmaptest': addr 60000000 IP 400548 error 7
kernel 0: user page fault in 'pmaptest': addr 60001000 IP 400548 error 7
pmaptest.0: array init done!
pmaptest.0: array check fail, a[0] = 1024
pmaptest.0: two page's content are identical
a[0] = 1024, a[1024] = 1024
a[1] = 1025, a[1025] = 1025
a[2] = 1026, a[1026] = 1026
a[3] = 1027, a[1027] = 1027
pmaptest.0: checking if the two virtual page share the same physical
page... no
pmaptest.0: begin one_page_one_frame test...
kernel 0: user page fault in 'pmaptest': addr 68000000 IP 4007b0 error 7
kernel 0: user page fault in 'pmaptest': addr 68001000 IP 4007b0 error 7
pmaptest.0: array init done
pmaptest.0: array check done!

During the porting, I've only changed find_ptable to get_ptable, Is it a
problem?

For you convenience, I attached a patch for
/lib/barrelfish/target/x86_32/pmap_target.c:modify_flags, in case you want
to test it by yourself.

Thanks for your concern!

Jinghao

On Mon, May 21, 2012 at 8:08 PM, Simon Peter <speter at inf.ethz.ch> wrote:

> Hi Jinghao,
>
> I've compiled your code for x86-64 and ran it on QEMU. Here's the output I
> get:
>
> pmaptest.0: begin monothelic_frame test...
> kernel 0: user page fault in 'pmaptest': addr 60000000 IP 4003a0, error 0x7
> kernel 0: user page fault in 'pmaptest': addr 60001000 IP 4003a0, error 0x7
> pmaptest.0: array init done!
> pmaptest.0: begin one_page_one_frame test...
> kernel 0: user page fault in 'pmaptest': addr 68000000 IP 400560, error 0x7
> kernel 0: user page fault in 'pmaptest': addr 68001000 IP 400560, error 0x7
> pmaptest.0: array init done
> pmaptest.0: array check done!
>
> This seems to be working?
>
> Simon
>
> On 20.05.2012 16:00, jhshi at cs.hku.hk wrote:
>
>> Here is my previous email, FYI.
>>
>> https://lists.inf.ethz.ch/**pipermail/barrelfish-users/**
>> 2012-May/000593.html<https://lists.inf.ethz.ch/pipermail/barrelfish-users/2012-May/000593.html>
>>
>> Quoting jhshi at cs.hku.hk:
>>
>>
>>> Hi,
>>>
>>> For some reason, I need to work on x86_32 instead of x86_64. And I
>>> found that x86_32's pmap->f.modify_flags is NYI. So I ported it from
>>>  x86_64, as described by my previous email (link). But then I found
>>> that the port won't work properly. Personally, I don't think the
>>> problem lies in the porting but in the modify_flags itself.
>>>
>>> Here is my test case workflow:
>>>
>>> First allocate two pages using frame_alloc and map them at some
>>> "safe"  virtual address as read-only using pmap->f.map. Then fill
>>> the two  pages with different content. Since they are read-only,
>>> page faults  will occur when filling. I catch them and map the fault
>>> page as  read-write using pmap->f.modify_flags in the fault handler.
>>> But then I  found that the two page's content are identical, which
>>> is not supposed  to be.
>>>
>>> Then I found that if I allocate one frame for each page, instead of
>>> one monolithic frame, everything is fine.
>>>
>>> I've summarized my test in the attached C file, which should be
>>> compiled and run under x86_32. Apology for not being able to test it
>>>  under X86_64 since I encounter some weird errors when compiling
>>> arch  x86_64. But if you substitute all the X86_32 to X86_64 in the
>>> test  file, it should work under x86_64 as well.
>>>
>>> However, if the test goes all fine under x86_64, then please give
>>> some  hint about why its x86_32's port would fail.
>>>
>>> Thanks in advance!
>>>
>>> Regards,
>>> Jinghao
>>>
>>>
>>
>> ______________________________**_________________
>> Barrelfish-users mailing list
>> Barrelfish-users at lists.inf.**ethz.ch <Barrelfish-users at lists.inf.ethz.ch>
>> https://lists.inf.ethz.ch/**mailman/listinfo/barrelfish-**users<https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20120521/abf782f7/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pmap_target_x86_32.patch
Type: application/octet-stream
Size: 1769 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20120521/abf782f7/attachment.obj