Re: [Xen-devel] [RFC PATCH 3/3] Implement 3-level event channel routines.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-01-09 at 11:24 +0000, Jan Beulich wrote:
> >>> On 09.01.13 at 11:56, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Wed, 2013-01-09 at 08:38 +0000, Jan Beulich wrote:
> >> >>> On 08.01.13 at 18:33, Wei Liu <Wei.Liu2@xxxxxxxxxx> wrote:
> >> > On Thu, 2013-01-03 at 11:35 +0000, Jan Beulich wrote:
> >> >> >>> On 31.12.12 at 19:22, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> >> >> >
> >> >> > +static void __unmap_l2_sel(struct vcpu *v)
> >> >> > +{
> >> >> > +    unsigned long mfn;
> >> >> > +
> >> >> > +    if ( v->evtchn_pending_sel_l2 != 0 )
> >> >> > +    {
> >> >> > +        unmap_domain_page_global(v->evtchn_pending_sel_l2);
> >> >> > +        mfn = virt_to_mfn(v->evtchn_pending_sel_l2);
> >> >> 
> >> >> virt_to_mfn() is not valid on the output of
> >> >> map_domain_page{,_global}() (same further down). Yes, there is
> >> >> at least one example of this in the existing code, but that's wrong
> >> >> too, and is getting eliminated by the 16Tb patch series I'm in the
> >> >> process of putting together.
> >> >> 
> >> > 
> >> > So what's the correct way to do this? Do I need to wait for your patch
> >> > series?
> >> 
> >> Considering that the old 32-bit case of map_domain_page()
> >> doesn't matter anymore,
> > 
> > We still care about it on 32-bit ARM FWIW. (I@m not sure if that
> > invalidates your advice below though)
> 
> Right - which would require ARM to implement
> domain_page_map_to_mfn() (so far used only in x86 and tmem
> code).

I only see it in x86 (specifically hvm_unmap_guest_frame) but I guess
this is a useful interface for ARM to implement in any case and it
doesn't look to be terribly hard.

> >>  using domain_page_map_to_mfn()
> >> here would be the way to go (while the 32-bit version of it
> >> didn't allow map_domain_page_global() to be handled through
> >> it, my 64-bit implementation of it will).
> >> 
> >> And of course there's the obvious alternative of storing the
> >> MFN rather than re-obtaining it in the teardown path.
> 
> This second option of course would alway be valid, without
> architecture specific changes.

Right.

Ian.


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