On 12/14/2010 05:45 PM, Yoder Stuart-B08248 wrote:
> -----Original Message----- > From: Avi Kivity [mailto:avi@xxxxxxxxxx] > Sent: Tuesday, December 14, 2010 2:49 AM > To: Hollis Blanchard > Cc: Yoder Stuart-B08248; Alexander Graf; kvm-ppc@xxxxxxxxxxxxxxx > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
