Re: [Xen-devel] [PATCH v6 5/5] xen: introduce XENMEM_pin

[Tim Deegan <tim@xxxxxxx>]

At 13:56 +0100 on 30 Sep (1380549398), Stefano Stabellini wrote:
> On Mon, 30 Sep 2013, Jan Beulich wrote:
> > > +
> > > +    if ( !is_hardware_domain(d) )
> > > +    {
> > > +        rc = -EPERM;
> > > +        goto fail;
> > > +    }
> > > +
> > > +    memflags |= MEMF_bits(domain_clamp_alloc_bitsize(
> > > +        d,
> > > +        XENMEMF_get_address_bits(pin.in.mem_flags) ? :
> > > +        (BITS_PER_LONG+PAGE_SHIFT)));
> > > +
> > > +    for ( ; i < pin.in.nr_extents; i++ )
> > > +    {
> > > +        if ( unlikely(__copy_from_guest_offset(
> > > +                      &gpfn, pin.in.extent_start, i, 1)) )
> > > +        {
> > > +            rc = -EFAULT;
> > > +            goto fail;
> > > +        }
> > > +
> > > +        if ( generic_fls64(gpfn << PAGE_SHIFT) > memflags )
> > 
> > Didn't you mean MEMF_bits(memflags) here?
> 
> memflags is set to MEMF_bits(XXX) in the assignment above
> 
> 
> > > +        {
> > > +            rc = -EINVAL;
> > > +            goto fail;
> > > +        }
> > > +
> > > +        rc = guest_physmap_pin_range(d, gpfn, pin.in.extent_order);
> > > +        if ( rc )
> > > +            goto fail;
> > > +
> > > +        for ( j = 0; j < (1UL << pin.in.extent_order); j++ )
> > > +        {
> > > +            mfn = gmfn_to_mfn(d, gpfn);
> > 
> > I'm afraid you didn't even build test this on x86: There's no
> > gmfn_to_mfn() there.
> 
> Argh. On x86 I'll call get_gfn_unshare and ASSERT that the page is not
> shared (guest_physmap_pin_range is not implemented on x86 but it should
> have definitely unshared the page or failed doing so).

On x86 can you not just ENOSYS the whole thing?

Tim.

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