[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 5/5] xen: introduce XENMEM_pin
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |