Xen devel - Apr 2005 - Clarifiation about WP bit CR0 and copy on write in Xen

Hello,

I see in xen/arch/x86/mm.c a note (at the very beginning of
the file) which says that Xen sets to 1 the WP bit of CR0
so that processors operationg in CPL 1 and 2 will be unable
to write read-only pages.
(When WP bit of CR0 is cleared (0) it says to ignore write protection
so all pages are writable in Supervisor more).
>From what is written there I understand that
this is done in order to prevent OS opetaing in CPL 1 and CPL 2 from
writing into the page tables (I assume the page tables are read only
and only the HyperVisor can update them).

Later, it says : "this is very unlikely to cause a problem for guest
OS''s, which will generally use the WP bit to simplify copy-on-write
implementation (in that case, OS wants a fault when it writes to
an application-supplied buffer)."

As I remember ,and I am not sure abouth the details,
in Linux (and other *NIX), when a process calls
fork() it creates another process , and the pages of the old process
are mapped to the new process; But they are marked
as read only (for the new process)) and  only when the process tries to 
write
to the page then a new page is created. (There is a page fault).So this 
fork()
method uses "copy on write".

Can anybody please elaborate more on this ? what is the simplification
of "Copy on Write" here? How does it uses the WP bit ?
Does XenoLinux (for example) has a different implementation of clone() than 
the usual implementation?


Regards,
Sting

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> As I remember ,and I am not sure abouth the details,
> in Linux (and other *NIX), when a process calls
> fork() it creates another process , and the pages of the old process
> are mapped to the new process; But they are marked
> as read only (for the new process)) and  only when the process tries to
> write
> to the page then a new page is created. (There is a page fault).So this
> fork()
> method uses "copy on write".
>
> Can anybody please elaborate more on this ? what is the simplification
> of "Copy on Write" here? How does it uses the WP bit ?
> Does XenoLinux (for example) has a different implementation of clone() than
> the usual implementation?
If you''re in Ring 3 (userspace) then you''ll always take a page
fault for
writing to a read only page.  The kernel can CoW the page and fix up your 
mappings.

Presumably (I''ve not actually checked) the kernel uses the WP bit to
ensure
the CoW fault happens if the kernel tries to write to some memory in the 
child process.  If WP wasn''t set, the child could do a read system call
and
the kernel could copy data into a page that''s shared with the parent
process.
It makes things simpler to use WP to ensure that a fault occurs (even in 
kernel mode) rather than having to programmatically check if a CoW should be 
done before the kernel writes to userspace.

As a result of this optimisation, guest OS kernels are written with the 
assumption that the WP bit is active.  Therefore it won''t affect
correct
operations if Xen makes sure it''s set.  If a guest OS relied on being
able to
ignore write protection whilst in the kernel, it would make it trickier to 
port to Xen.

Of course, under Vanderpool / Pacifica, any strange guests that do want WP 
switched off will be able to run happily.

Cheers,
Mark

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel