This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] possible grant table issue

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] possible grant table issue
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Tue, 12 Jul 2005 18:14:08 -0400
Delivery-date: Tue, 12 Jul 2005 22:12:56 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

Attached is a patch that dumps some debugging output for the block 
interface backend. The reason why I am posting this patch is due to the 
somewhat strange assignments of the handles that are returned from the 
HYPERVISOR_grant_table_op. I am stopping short of saying it's a bug, 
because I don't know the code well enough, but when looking at the 
hypervisor code I see some place where I doubt that this is right. 
Particularly one should try the following:

Create user domains that use the block interfaces.

1st user domain witll be assigned handle 0x0. - should be ok
2nd user domain will be assigned handle 0x1. - should be ok
3rd user domain will be assigned handle 0x2. - should be ok

(handle numbers have obviously been increasing so far)

bring down 3rd user domain - free'ed handle will be 0x2 - should be ok

create 3rd user domain again - will be assigned handle 0x0 - this is not 
what I would expect.

(the code that's causing this is called when handle 0x2 was free'ed
static inline void
            grant_table_t *t, int handle)
            t->maptrack[handle].ref_and_flags = t->maptrack_head << 
            t->maptrack_head = handle;

Now when I look  at xen/common/grant_tables.c I see how the handles are 
used in :

static int
    gnttab_map_grant_ref_t *uop,
    unsigned long *va)
        [...] // much omitted

    if ( 0 <= ( rc = __gnttab_activate_grant_ref( ld, led, rd, ref,
         * Only make the maptrack live _after_ writing the pte, in case we 

         * overwrite the same frame number, causing a maptrack walk to 
find it
        ld->grant_table->maptrack[handle].domid = dom;
            = (ref << MAPTRACK_REF_SHIFT) |
              (dev_hst_ro_flags & MAPTRACK_GNTMAP_MASK);

        (void)__put_user(frame, &uop->dev_bus_addr);

        if ( dev_hst_ro_flags & GNTMAP_host_map )
            *va = host_virt_addr;

        (void)__put_user(handle, &uop->handle);

I think this newly assigned handle of '0' (for the re-created 3rd user 
domain) is overwriting some previously assign array entry for the first 
user domain. Please someone who knows have a look at this. All this is 
happening in the domain where the blockdevice backend is located.


Signed-off-by : Stefan Berger <stefanb@xxxxxxxxxx>

Attachment: blkif_debug.patch
Description: Binary data

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>