[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Creating a magic page for PV mem_access

  • To: Tim Deegan <tim@xxxxxxx>
  • From: "Aravindh Puthiyaparambil (aravindp)" <aravindp@xxxxxxxxx>
  • Date: Mon, 3 Jun 2013 19:11:59 +0000
  • Accept-language: en-US
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 03 Jun 2013 19:13:44 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac5eZC/YqEr6q0y7T8OUPDoRI/xcdgCAbxKAAAlCbCA=
  • Thread-topic: Creating a magic page for PV mem_access

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Monday, June 03, 2013 2:24 AM
> To: Aravindh Puthiyaparambil (aravindp)
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: Creating a magic page for PV mem_access
> Hi,
> At 01:24 +0000 on 01 Jun (1370049844), 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.

On seeing console here sent me down the path of trying to do the same for the 
PV access ring page akin to what was being done for PV console page.

> > With HVM domains, xc_set_hvm_param() is used by the tools to populate
> > this on the hypervisor side. What is the method I should follow to do
> > this for PV domains? I see how things work for the console, xenconsole
> > pages as they get passed through the start_info structure. Do I need
> > to implement an equivalent
> > xc_set_pv_param() or do I use the start_info page to store the
> > mem_access magic page address?
> Again, that depends on what the page is used for.  If the guest needs to
> access it, then it needs to find out about it somehow, but the usual way to
> pass that kind of config info to the guest is using Xenstore.  If the guest
> needs to be involved right form the start of day (i.e. before Xenbus gets
> going) it might have to go in the start_info, but that's a less attractive 
> option.

The guest does not need to know about this page so we definitely do not need to 
use start_info.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.