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

Re: [Xen-devel] Questions regarding implementing mem_event for PV


  • To: Tim Deegan <tim@xxxxxxx>
  • From: "Aravindh Puthiyaparambil (aravindp)" <aravindp@xxxxxxxxx>
  • Date: Thu, 17 Oct 2013 21:34:07 +0000
  • Accept-language: en-US
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 17 Oct 2013 21:34:38 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac7K1BwQAaArcrcSQ12vDlA5WCgCHwAwAiKAAApYi3AAEHYdUA==
  • Thread-topic: Questions regarding implementing mem_event for PV

> -----Original Message-----
> From: Aravindh Puthiyaparambil (aravindp)
> Sent: Thursday, October 17, 2013 12:00 PM
> To: 'Tim Deegan'
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: Questions regarding implementing mem_event for PV
> 
> > > I am looking in to implementing mem_event for PV guests that use PV
> > mmu_ops. Initially I am thinking of supporting 64-bit PV guests. I think 
> > only
> > RW, RX and R permissions would be possible. I am looking at the hypercall
> > interfaces that do the pagetable manipulations. In addition to the
> hypercalls I
> > am also looking at the pagetable write emulation code.
> > >
> > > My plan is to set the page permissions in:
> > > do_mmu_update()
> > > do_mmuext_op(MMUEXT_PIN_L1_TABLE)
> > > __do_update_va_mapping()
> > > ptwr_emulated_update()
> > >
> >
> > I'm afraid you can't do that, and still support the PV API as it
> > stands.  The guest had read access to its pagetables, and it does not
> > expect Xen to change them underfoot.  E.g. if you temporarily mark a
> > page as inaccessible and the guest walks its own pagetables to
> > diagnose a page fault, it could see your change and send SIGSEGV to
> > the current process.
> >
> > So if you want to have permissions in the pagetables that aren't the
> > ones the guest asked for, your choices are:
> >
> >  (a) use shadow pagetables.  This is what the live migration code
> >      does in order to intercept writes for tracking memory dirtying.
> >      Slow, but should work for most things.
> >
> >  (b) Wait for the PVH patch series to go in (and the equivalent
> >      series in Linux and FreeBSD kernels).  PVH guests are enough
> >      like HVM ones in the Xen code that mem_events will be much easier.
> >
> > (b) is probably much eaier, if you have the choice.
> 
> I don't have the choice of waiting for (b) so I guess I would have to go down
> the harder (a) route. Let me explore that and get back to you with my
> thoughts.

Is there an xl config file option to bring up a PV guest with shadow? Or do I 
have to call xc_shadow_control() from the mem_event handler to enable shadow 
paging for a PV guest?

Thanks,
Aravindh


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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