Re: Creating a magic page for PV mem_access

[Tim Deegan <tim@xen.org>]

Hi,

At 19:11 +0000 on 03 Jun (1370286719), Aravindh Puthiyaparambil (aravindp) wrote:
> > > I am trying to create a magic / special page for the PV mem_access. I
> > > am mimicking what is being done for the console page
> > > (alloc_magic_pages()) on the tools side. On the hypervisor side, I am
> > > planning on stashing the address of this page in the pv_domain
> > > structure akin to how the special pages are stored in params[] of the
> > > hvm_domain structure.
> > 
> > OK, can you back up a bit and describe what you're going to use this page
> > for?  A PV domain's 'magic' pages may not be quite what you want.
> > First, they're owned by the guest, so the guest can write to them (and so
> > they can't be trusted for doing hypervisor->dom0 communications).
> 
> You are right. I didn't realize magic pages are writable by the
> guest. So this is not a good option.
> 
> > And second, I'm not sure that mem_access pages really need to
> > saved/restored with the rest of the VM -- I'd have thought that you could
> > just set up a new, empty ring on the far side.
> 
> I am trying to mimic what is being done in the HVM side for mem_event
> pages. In setup_guest() (xc_hvm_build_x86.c), I see "special pages"
> being created for console, paging, access and sharing ring pages. Then
> xc_set_hvm_param() is used to inform the hypervisor. When a mem_event
> / mem_access client comes up, it uses xc_get_hvm_param() to get the
> pfn and maps it in. I want to do something similar for PV.

Yep.  I think it might be better to invent up a new interface for those
pages, rather than using domain memory for them.  We can then deprecate
the old HVM-specific params interface.

Tim.