Re: re-writing on powerpc

[Avi Kivity <avi@redhat.com>]

On 12/14/2010 05:45 PM, Yoder Stuart-B08248 wrote:
> >  -----Original Message-----
> >  From: Avi Kivity [mailto:avi@redhat.com]
> >  Sent: Tuesday, December 14, 2010 2:49 AM
> >  To: Hollis Blanchard
> >  Cc: Yoder Stuart-B08248; Alexander Graf; kvm-ppc@vger.kernel.org
> >  Subject: Re: re-writing on powerpc
> >
> >  On 12/13/2010 07:17 PM, Hollis Blanchard wrote:
> >  >>  Rewriting is dangerous if the guest is unaware of it.  As soon as
> it
> >  >>  is made aware of it, it might as well actually do it in the best
> way
> >  >>  that suits it.
> >  >
> >  >  Can you list some examples of dangerous scenarios?
> >  >
> >
> >  - guest checksums own kernel pages
> >  - clever compiler reuses code for constant pool
> >  - guest patches itself (a la linux alternatives), surprised when it
> sees a
> >  different instruction
> >  - guest jits own kernel code (like Singularity), gets confused when it
> >  reads back something it didn't write
>
> One possible solution to hiding rewriting from guest if it must
> be hidden is to mark patched pages as execute only.  If a guest
> reads a patched page, the hypervisor can fix up the read.
>

Yes.  Something that is common to all the problems above is "using code 
as data".

However, execute only would only affect the page's mapping, not the page 
itself, yes?  So if the page has another mapping, this doesn't work.

Of course the guest is not completely unaware of patching, so we can 
say, if the guest requests patching it becomes its responsibility not to 
do silly stuff.  I still prefer guest patching though.

> For KVM on powerpc, I'm not sure that having the guest be
> completely unaware of the presence of a hypervisor is what
> we need to be necessarily shooting for.   What has been worked on in
> the embedded virtualization committee in power.org is that
> we expect there to be a /hypervisor node in the guest device
> tree with certain standard properties, including ones indicating
> if the hypervisor support a shared area or re-writing.  The
> guest makes an hcall indicating if it wants to enable rewriting.
>
> So the guest would need to be aware that it needs to checksum
> before enabling this.
>
> The problem is how much guest modification is needed--  some hcalls
> to enable rewriting seems manageable.  Changing every OS for
> the paravirt interface involves a lot more work.

If a spec exists for hypervisor controlled rewriting, that changes the 
picture considerably.  Presumably the spec lays out all the constraints 
in detail, so we don't have to worry about that.

-- 
error compiling committee.c: too many arguments to function