[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 18:59:47 +0000
  • Accept-language: en-US
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 17 Oct 2013 19:00:16 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac7K1BwQAaArcrcSQ12vDlA5WCgCHwAwAiKAAApYi3A=
  • Thread-topic: 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.


> > The default functions for p2m->set_entry() and p2m->get_entry()
> > default to the shadow PT variants which I am assuming cannot be used
> > in the PV cases and I would need to do something along the lines of
> > mod_l1_entry(). Is this correct?
> PV guests don't have a p2m in Xen -- they put MFNs directly in their
> pagetabels and Xen only checks the pagetables for safety.  The guest
> itself will probably have an internal p2m for bookkeeping (and for
> save/restore) but again Xen isn't allowed to write to it.
> Cheers,
> Tim.

Xen-devel mailing list



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