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] Re: [PATCH] libxl: fix xenstore connection when run in d

To: Patrick Colp <pjcolp@xxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: 答复: [Xen-devel] Re: [PATCH] libxl: fix xenstore connection when run in domU
From: "Jun Zhu (Intern)" <Jun.Zhu@xxxxxxxxxx>
Date: Wed, 1 Sep 2010 09:40:16 +0100
Accept-language: zh-CN, en-US
Acceptlanguage: zh-CN, en-US
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "dgdegra@xxxxxxxxxxxxx" <dgdegra@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 01 Sep 2010 01:41:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTimiVnYpwzGbg0CmA4NEaraLx4xS5fMdNmethaGf@xxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <433DDF91DFB08148BAD3FDB6FDDA314C9F35F3BB4F@xxxxxxxxxxxxxxxxxxxxxxxxx> <1283246119.12544.9287.camel@xxxxxxxxxxxxxxxxxxxxxx> <20100831102851.GB23648@xxxxxxxxxxxxxxxxxxxxxxx> <433DDF91DFB08148BAD3FDB6FDDA314C9F35F3BB53@xxxxxxxxxxxxxxxxxxxxxxxxx> <1283251461.12544.9403.camel@xxxxxxxxxxxxxxxxxxxxxx>, <AANLkTimiVnYpwzGbg0CmA4NEaraLx4xS5fMdNmethaGf@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActJNR/Tt8+IzmQ6RzCW+rURUblGZAAebrGF
Thread-topic: [Xen-devel] Re: [PATCH] libxl: fix xenstore connection when run in domU
In pvops, in the function  xenbus_file_write of file drivers/xen/xenfs/xenbus.c.
In the switch, there is no XS_INTRODUCE which is used to create a new domain.
These commands are eliminated here, since in default, a Domu cannot use these 

static ssize_t xenbus_file_write(struct file *filp,
                                const char __user *ubuf,
                                size_t len, loff_t *ppos)
        struct xenbus_file_priv *u = filp->private_data;
        uint32_t msg_type;
        int rc = len;
        int ret;

         * We're expecting usermode to be writing properly formed
         * xenbus messages.  If they write an incomplete message we
         * buffer it up.  Once it is complete, we act on it.

         * Make sure concurrent writers can't stomp all over each
         * other's messages and make a mess of our partial message
         * buffer.  We don't make any attemppt to stop multiple
         * writers from making a mess of each other's incomplete
         * messages; we're just trying to guarantee our own internal
         * consistency and make sure that single writes are handled
         * atomically.

        /* Get this out of the way early to avoid confusion */
        if (len == 0)
                goto out;

        /* Can't write a xenbus message larger we can buffer */
        if ((len + u->len) > sizeof(u->u.buffer)) {
                /* On error, dump existing buffer */
                u->len = 0;
                rc = -EINVAL;
                goto out;

        ret = copy_from_user(u->u.buffer + u->len, ubuf, len);

        if (ret == len) {
                rc = -EFAULT;
                goto out;

        /* Deal with a partial copy. */
        len -= ret;
        rc = len;

        u->len += len;

        /* Return if we haven't got a full message yet */
        if (u->len < sizeof(u->u.msg))
                goto out;       /* not even the header yet */

        /* If we're expecting a message that's larger than we can
           possibly send, dump what we have and return an error. */
        if ((sizeof(u->u.msg) + u->u.msg.len) > sizeof(u->u.buffer)) {
                rc = -E2BIG;
                u->len = 0;
                goto out;

        if (u->len < (sizeof(u->u.msg) + u->u.msg.len))
                goto out;       /* incomplete data portion */

         * OK, now we have a complete message.  Do something with it.

        msg_type = u->u.msg.type;

        switch (msg_type) {
        case XS_TRANSACTION_END:
        case XS_DIRECTORY:
        case XS_READ:
        case XS_GET_PERMS:
        case XS_RELEASE:
        case XS_GET_DOMAIN_PATH:
        case XS_WRITE:
        case XS_MKDIR:
        case XS_RM:
        case XS_SET_PERMS:
                /* Send out a transaction */
                ret = xenbus_write_transaction(msg_type, u);

        case XS_WATCH:
        case XS_UNWATCH:
                /* (Un)Ask for some path to be watched for changes */
                ret = xenbus_write_watch(msg_type, u);

                ret = -EINVAL;
        if (ret != 0)
                rc = ret;

        /* Buffered message consumed */
        u->len = 0;

        return rc;

Jun Zhu
Citrix Systems UK
发件人: Patrick Colp [pjcolp@xxxxxxxxx]
发送时间: 2010年8月31日 下午 1:51
收件人: Ian Campbell
抄送: Jun Zhu (Intern); Tim Deegan; dgdegra@xxxxxxxxxxxxx; 
主题: Re: [Xen-devel] Re: [PATCH] libxl: fix xenstore connection when run in domU

Which XenBus driver is this? In Linux? I've certainly had no issues
running a Mini-OS XenStore stubdom (at least not in regards to missing
things like XS_INTRODUCE).


On 31 August 2010 03:44, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Tue, 2010-08-31 at 11:32 +0100, Jun Zhu (Intern) wrote:
>> If xenstore runs in a seperate domain, it must use xenbus dev to
>> communicate. If so, the xenstore commands in Xenbus driver are not
>> complete. For example, it does not contain XS_INTRODUCE now.
> IIRC Diego's original xenstore-stubdom patch series from way back when
> (posted to the list by Diego and again later by Alex Zeffertt) included
> patches to the kernel side xenbus driver to resolve issues like this.
> Ian.
Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>