|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/4] xen/arm: implement page reference and grant table functions needed by grant_table.c
At 12:05 +0100 on 04 Jul (1341403532), Stefano Stabellini wrote:
> The implementation is strongly "inspired" by their x86 counterparts,
> except that we assume paging_mode_external and paging_mode_translate.
>
> TODO: read_only mappings and gnttab_mark_dirty.
Do we actually need these refcounts on ARM? Or was it just the
typecount we thought we could do without?
> +struct domain *page_get_owner_and_reference(struct page_info *page)
> +{
> + unsigned long x, y = page->count_info;
> +
> + do {
> + x = y;
> + /*
> + * Count == 0: Page is not allocated, so we cannot take a reference.
> + * Count == -1: Reference count would wrap, which is invalid.
> + * Count == -2: Remaining unused ref is reserved for
> get_page_light().
> + */
> + if ( unlikely(((x + 2) & PGC_count_mask) <= 2) )
> + return NULL;
> + }
> + while ( (y = cmpxchg(&page->count_info, x, x + 1)) != x );
get_page_light() is an x86-ism, so we don't need to leave room for it here.
> +void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
> +{
> + /*
> + * Note that this cannot be clear_bit(), as the access must be
> + * confined to the specified 2 bytes.
> + */
> + uint16_t mask = ~(1 << nr), old;
> +
> + do {
> + old = *addr;
A hard tab has snuck in here.
> + } while (cmpxchg(addr, old, old & mask) != old);
This could be done more efficiently with the underlying LRREXH/STREXH
instructions but maybe not worth it? Is this on any hot paths?
> +}
> +
> +void gnttab_mark_dirty(struct domain *d, unsigned long l)
> +{
> + /* XXX: mark dirty */
> +}
> +
> +int create_grant_host_mapping(unsigned long addr, unsigned long frame,
> + unsigned int flags, unsigned int cache_flags)
> +{
> + int rc;
> +
> + if ( cache_flags || (flags & ~GNTMAP_readonly) != GNTMAP_host_map )
> + return GNTST_general_error;
> +
> + /* XXX: read only mappings
> + if ( flags & GNTMAP_readonly )
> + p2mt = p2m_grant_map_ro;
> + else
> + p2mt = p2m_grant_map_rw;
> + */
> + rc = guest_physmap_add_page(current->domain,
> + addr >> PAGE_SHIFT, frame, 0);
I'm a little worried about taking this in, in case we never get round to
making the read-only grants read-only. Could we get away with making
that an error case or are they needed right now?
Cheers,
Tim.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |