Hi all,
In xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv function, there are
several lines as follow:
437 mutex_lock(&h->request_mutex);
438
439 if (!xs_write_all(h->fd, &msg, sizeof(msg)))
440 goto fail;
441
442 for (i = 0; i < num_vecs; i++)
443 if (!xs_write_all(h->fd, iovec[i].iov_base,
iovec[i].iov_len))
444 goto fail;
445
446 ret = read_reply(h, &msg.type, len);
447 if (!ret)
448 goto fail;
449
450 mutex_unlock(&h->request_mutex);
The above seems to tell me that after writing to h->fd , the read_reply
invoking read_message which immediatelly read from hd->fd?
What did it mean by this?
Thanks
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com> wrote:> Hi all, > > In xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv function, there are > several lines as follow: > > 437 mutex_lock(&h->request_mutex); > > > > 438 > > > > 439 if (!xs_write_all(h->fd, &msg, sizeof(msg))) > > > > 440 goto fail; > > > > 441 > > > > 442 for (i = 0; i < num_vecs; i++) > > > > 443 if (!xs_write_all(h->fd, iovec[i].iov_base, > iovec[i].iov_len)) > > > 444 goto fail; > > > > 445 > > > > 446 ret = read_reply(h, &msg.type, len); > > > > 447 if (!ret) > > > > 448 goto fail; > > > > 449 > > > > 450 mutex_unlock(&h->request_mutex); > > > The above seems to tell me that after writing to h->fd , the read_reply > invoking read_message which immediatelly read from hd->fd? > What did it mean by this? > > > Thanks >If hd->fd refers to a socket descriptor, it''s understandable that writing and then imediatelly reading, in which case the fd is returned by get_handle(xs_daemon_socket(), flags). But when fd is retrived by get_handle(xs_domain_dev(), flags), it means to write to a file and then read from the same file imediatelly. Dose it have something to do with the internal communication protocol?! Thanks for replying. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell
2012-Aug-09 08:21 UTC
Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`
On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote:> > > On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com> wrote: > Hi all, > > In xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv function, > there are several lines as follow: > > > 437 mutex_lock(&h->request_mutex); > > > > 438 > > > > 439 if (!xs_write_all(h->fd, &msg, sizeof(msg))) > > > > 440 goto fail; > > > > 441 > > > > 442 for (i = 0; i < num_vecs; i++) > > > > 443 if (!xs_write_all(h->fd, > iovec[i].iov_base, iovec[i].iov_len)) > > > > 444 goto fail; > > > > 445 > > > > 446 ret = read_reply(h, &msg.type, len); > > > > 447 if (!ret) > > > > 448 goto fail; > > > > 449 > > > > 450 mutex_unlock(&h->request_mutex); > > > > > The above seems to tell me that after writing to h->fd , the > read_reply invoking read_message which immediatelly read from > hd->fd? > What did it mean by this? > > > > > Thanks > > If hd->fd refers to a socket descriptor, it's understandable that > writing and then imediatelly reading, in which case the fd is returned > by get_handle(xs_daemon_socket(), flags). > > > But when fd is retrived by get_handle(xs_domain_dev(), flags), it > means to write to a file and then read from the same file imediatelly. > Dose it have something to do with the internal communication > protocol?!Yes, the xenstore protocol involves both writing messages and reading replies, but that seems trivially obvious so I'm afraid I really have no idea what your question is nor what is confusing you. Perhaps describing in more detail what you are trying to achieve will help? Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions might also help you consider what it is you are asking.> > > Thanks for replying. > > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, Aug 9, 2012 at 4:21 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote: > > > > > > On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com> wrote: > > Hi all, > > > > In xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv function, > > there are several lines as follow: > > > > > > 437 mutex_lock(&h->request_mutex); > > > > > > > > 438 > > > > > > > > 439 if (!xs_write_all(h->fd, &msg, sizeof(msg))) > > > > > > > > 440 goto fail; > > > > > > > > 441 > > > > > > > > 442 for (i = 0; i < num_vecs; i++) > > > > > > > > 443 if (!xs_write_all(h->fd, > > iovec[i].iov_base, iovec[i].iov_len)) > > > > > > > > 444 goto fail; > > > > > > > > 445 > > > > > > > > 446 ret = read_reply(h, &msg.type, len); > > > > > > > > 447 if (!ret) > > > > > > > > 448 goto fail; > > > > > > > > 449 > > > > > > > > 450 mutex_unlock(&h->request_mutex); > > > > > > > > > > The above seems to tell me that after writing to h->fd , the > > read_reply invoking read_message which immediatelly read from > > hd->fd? > > What did it mean by this? > > > > > > > > > > Thanks > > > > If hd->fd refers to a socket descriptor, it''s understandable that > > writing and then imediatelly reading, in which case the fd is returned > > by get_handle(xs_daemon_socket(), flags). > > > > > > But when fd is retrived by get_handle(xs_domain_dev(), flags), it > > means to write to a file and then read from the same file imediatelly. > > Dose it have something to do with the internal communication > > protocol?! > > Yes, the xenstore protocol involves both writing messages and reading > replies, but that seems trivially obvious so I''m afraid I really have no > idea what your question is nor what is confusing you. Perhaps describing > in more detail what you are trying to achieve will help? > > Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions might also > help you consider what it is you are asking. > > > > > > > > Thanks for replying. > > > > > > > > > > > > > >Sorry about that, pehaps it results from my lacking of rudimentary knowledge. IIRC, when using socket, there are two buffers of which one is for sending and another for receiving, so I said ''If hd->fd refers to a socket descriptor, it''s understandable that> writing and then imediatelly reading,''But when fd is retrived by get_handle(xs_domain_dev(), flags), it seems that sender and receiver both writing to the same file, I have no idea about the file /proc/xen/xenbus for communicating between domains? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell
2012-Aug-09 09:49 UTC
Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`
On Thu, 2012-08-09 at 10:42 +0100, 马磊 wrote:> > > On Thu, Aug 9, 2012 at 4:21 PM, Ian Campbell <Ian.Campbell@citrix.com> > wrote: > On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote: > > > > > > On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com> > wrote: > > Hi all, > > > > In xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv > function, > > there are several lines as follow: > > > > > > 437 mutex_lock(&h->request_mutex); > > > > > > > > 438 > > > > > > > > 439 if (!xs_write_all(h->fd, &msg, > sizeof(msg))) > > > > > > > > 440 goto fail; > > > > > > > > 441 > > > > > > > > 442 for (i = 0; i < num_vecs; i++) > > > > > > > > 443 if (!xs_write_all(h->fd, > > iovec[i].iov_base, iovec[i].iov_len)) > > > > > > > > 444 goto fail; > > > > > > > > 445 > > > > > > > > 446 ret = read_reply(h, &msg.type, len); > > > > > > > > 447 if (!ret) > > > > > > > > 448 goto fail; > > > > > > > > 449 > > > > > > > > 450 mutex_unlock(&h->request_mutex); > > > > > > > > > > The above seems to tell me that after writing to > h->fd , the > > read_reply invoking read_message which immediatelly > read from > > hd->fd? > > What did it mean by this? > > > > > > > > > > Thanks > > > > If hd->fd refers to a socket descriptor, it's understandable > that > > writing and then imediatelly reading, in which case the fd > is returned > > by get_handle(xs_daemon_socket(), flags). > > > > > > But when fd is retrived by get_handle(xs_domain_dev(), > flags), it > > means to write to a file and then read from the same file > imediatelly. > > Dose it have something to do with the internal communication > > protocol?! > > > Yes, the xenstore protocol involves both writing messages and > reading > replies, but that seems trivially obvious so I'm afraid I > really have no > idea what your question is nor what is confusing you. Perhaps > describing > in more detail what you are trying to achieve will help? > > Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions > might also > help you consider what it is you are asking. > > > > > > > > Thanks for replying. > > > > > > > > > > > > > > > > Sorry about that, pehaps it results from my lacking of rudimentary > knowledge. > IIRC, when using socket, there are two buffers of which one is for > sending and another for receiving, so I said 'If hd->fd refers to a > socket descriptor, it's understandable that > > writing and then imediatelly reading,' > > > But when fd is retrived by get_handle(xs_domain_dev(), flags), it > seems that sender and receiver both writing to the same file, I have > no idea about the file /proc/xen/xenbus for communicating between > domains?/proc/xen/xenbus is a virtual device which arbitrates access to the xenbus ring, which in turn is used to communicate with the xenstore daemon. You could think of an fd onto this device as a socket connected to the xenstore daemon. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, Aug 9, 2012 at 4:21 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote: > > > > > > On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com> wrote: > > Hi all, > > > > In xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv function, > > there are several lines as follow: > > > > > > 437 mutex_lock(&h->request_mutex); > > > > > > > > 438 > > > > > > > > 439 if (!xs_write_all(h->fd, &msg, sizeof(msg))) > > > > > > > > 440 goto fail; > > > > > > > > 441 > > > > > > > > 442 for (i = 0; i < num_vecs; i++) > > > > > > > > 443 if (!xs_write_all(h->fd, > > iovec[i].iov_base, iovec[i].iov_len)) > > > > > > > > 444 goto fail; > > > > > > > > 445 > > > > > > > > 446 ret = read_reply(h, &msg.type, len); > > > > > > > > 447 if (!ret) > > > > > > > > 448 goto fail; > > > > > > > > 449 > > > > > > > > 450 mutex_unlock(&h->request_mutex); > > > > > > > > > > The above seems to tell me that after writing to h->fd , the > > read_reply invoking read_message which immediatelly read from > > hd->fd? > > What did it mean by this? > > > > > > > > > > Thanks > > > > If hd->fd refers to a socket descriptor, it''s understandable that > > writing and then imediatelly reading, in which case the fd is returned > > by get_handle(xs_daemon_socket(), flags). > > > > > > But when fd is retrived by get_handle(xs_domain_dev(), flags), it > > means to write to a file and then read from the same file imediatelly. > > Dose it have something to do with the internal communication > > protocol?! > > Yes, the xenstore protocol involves both writing messages and reading > replies, but that seems trivially obvious so I''m afraid I really have no > idea what your question is nor what is confusing you. Perhaps describing > in more detail what you are trying to achieve will help? > > Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions might also > help you consider what it is you are asking. > > > > > > > > Thanks for replying. > > > > > > > > > > > > > The final read and write operations are achieved by:read(fd, data, len); write(fd, data, len); Maybe my confusing lies in this point that what''s the distinction between the read and write operations on a socket file, the /proc/xen/xenbus, a regular file? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell
2012-Aug-09 09:58 UTC
Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`
On Thu, 2012-08-09 at 10:50 +0100, 马磊 wrote:> > > On Thu, Aug 9, 2012 at 4:21 PM, Ian Campbell <Ian.Campbell@citrix.com> > wrote: > On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote: > > > > > > On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com> > wrote: > > Hi all, > > > > In xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv > function, > > there are several lines as follow: > > > > > > 437 mutex_lock(&h->request_mutex); > > > > > > > > 438 > > > > > > > > 439 if (!xs_write_all(h->fd, &msg, > sizeof(msg))) > > > > > > > > 440 goto fail; > > > > > > > > 441 > > > > > > > > 442 for (i = 0; i < num_vecs; i++) > > > > > > > > 443 if (!xs_write_all(h->fd, > > iovec[i].iov_base, iovec[i].iov_len)) > > > > > > > > 444 goto fail; > > > > > > > > 445 > > > > > > > > 446 ret = read_reply(h, &msg.type, len); > > > > > > > > 447 if (!ret) > > > > > > > > 448 goto fail; > > > > > > > > 449 > > > > > > > > 450 mutex_unlock(&h->request_mutex); > > > > > > > > > > The above seems to tell me that after writing to > h->fd , the > > read_reply invoking read_message which immediatelly > read from > > hd->fd? > > What did it mean by this? > > > > > > > > > > Thanks > > > > If hd->fd refers to a socket descriptor, it's understandable > that > > writing and then imediatelly reading, in which case the fd > is returned > > by get_handle(xs_daemon_socket(), flags). > > > > > > But when fd is retrived by get_handle(xs_domain_dev(), > flags), it > > means to write to a file and then read from the same file > imediatelly. > > Dose it have something to do with the internal communication > > protocol?! > > > Yes, the xenstore protocol involves both writing messages and > reading > replies, but that seems trivially obvious so I'm afraid I > really have no > idea what your question is nor what is confusing you. Perhaps > describing > in more detail what you are trying to achieve will help? > > Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions > might also > help you consider what it is you are asking. > > > > > > > > Thanks for replying. > > > > > > > > > > > > > The final read and write operations are achieved by: > read(fd, data, len); > write(fd, data, len); > > > Maybe my confusing lies in this point that what's the distinction > between the read and write operations on a socket file, > the /proc/xen/xenbus, a regular file?/proc/xen/xenbus is not a regular file. /proc is a virtual file system where the files often have special and magic semantics. /proc/xen/xenbus is effectively something like a character device, even though it isn't actually implemented as one. Take a look at drivers/xen/xenbus/xenbus_dev_frontend.c which is the driver which backends /proc/xen/xenbus Ian. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, Aug 9, 2012 at 5:58 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Thu, 2012-08-09 at 10:50 +0100, 马磊 wrote: > > > > > > On Thu, Aug 9, 2012 at 4:21 PM, Ian Campbell <Ian.Campbell@citrix.com> > > wrote: > > On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote: > > > > > > > > > On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com> > > wrote: > > > Hi all, > > > > > > In xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv > > function, > > > there are several lines as follow: > > > > > > > > > 437 mutex_lock(&h->request_mutex); > > > > > > > > > > > > 438 > > > > > > > > > > > > 439 if (!xs_write_all(h->fd, &msg, > > sizeof(msg))) > > > > > > > > > > > > 440 goto fail; > > > > > > > > > > > > 441 > > > > > > > > > > > > 442 for (i = 0; i < num_vecs; i++) > > > > > > > > > > > > 443 if (!xs_write_all(h->fd, > > > iovec[i].iov_base, iovec[i].iov_len)) > > > > > > > > > > > > 444 goto fail; > > > > > > > > > > > > 445 > > > > > > > > > > > > 446 ret = read_reply(h, &msg.type, len); > > > > > > > > > > > > 447 if (!ret) > > > > > > > > > > > > 448 goto fail; > > > > > > > > > > > > 449 > > > > > > > > > > > > 450 mutex_unlock(&h->request_mutex); > > > > > > > > > > > > > > > The above seems to tell me that after writing to > > h->fd , the > > > read_reply invoking read_message which immediatelly > > read from > > > hd->fd? > > > What did it mean by this? > > > > > > > > > > > > > > > Thanks > > > > > > If hd->fd refers to a socket descriptor, it''s understandable > > that > > > writing and then imediatelly reading, in which case the fd > > is returned > > > by get_handle(xs_daemon_socket(), flags). > > > > > > > > > But when fd is retrived by get_handle(xs_domain_dev(), > > flags), it > > > means to write to a file and then read from the same file > > imediatelly. > > > Dose it have something to do with the internal communication > > > protocol?! > > > > > > Yes, the xenstore protocol involves both writing messages and > > reading > > replies, but that seems trivially obvious so I''m afraid I > > really have no > > idea what your question is nor what is confusing you. Perhaps > > describing > > in more detail what you are trying to achieve will help? > > > > Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions > > might also > > help you consider what it is you are asking. > > > > > > > > > > > > > Thanks for replying. > > > > > > > > > > > > > > > > > > > > The final read and write operations are achieved by: > > read(fd, data, len); > > write(fd, data, len); > > > > > > Maybe my confusing lies in this point that what''s the distinction > > between the read and write operations on a socket file, > > the /proc/xen/xenbus, a regular file? > > /proc/xen/xenbus is not a regular file. /proc is a virtual file system > where the files often have special and magic semantics. /proc/xen/xenbus > is effectively something like a character device, even though it isn''t > actually implemented as one. > > Take a look at drivers/xen/xenbus/xenbus_dev_frontend.c which is the > driver which backends /proc/xen/xenbus > > Ian. > > > Ian. > > > >I didn''t find the xenbus_dev_frontend.c by `` find / -name "*xenbus*" 2>/dev/null `` command. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell
2012-Aug-09 10:28 UTC
Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`
On Thu, 2012-08-09 at 11:21 +0100, 马磊 wrote:> I didn't find the xenbus_dev_frontend.c by `` find / -name "*xenbus*" > 2>/dev/null `` command.Look in the upstream Linux kernel source. In some older kernels it is drivers/xen/xenbus/xenbus_dev.c Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell
2012-Aug-09 10:31 UTC
Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`
On Thu, 2012-08-09 at 11:28 +0100, Ian Campbell wrote:> On Thu, 2012-08-09 at 11:21 +0100, 马磊 wrote: > > > I didn't find the xenbus_dev_frontend.c by `` find / -name "*xenbus*" > > 2>/dev/null `` command. > > Look in the upstream Linux kernel source. > > In some older kernels it is > drivers/xen/xenbus/xenbus_dev.cAlso please try using a search engine to answer these questions. This driver is trivially found with google. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, Aug 9, 2012 at 6:31 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Thu, 2012-08-09 at 11:28 +0100, Ian Campbell wrote: > > On Thu, 2012-08-09 at 11:21 +0100, 马磊 wrote: > > > > > I didn''t find the xenbus_dev_frontend.c by `` find / -name "*xenbus*" > > > 2>/dev/null `` command. > > > > Look in the upstream Linux kernel source. > > > > In some older kernels it is > > drivers/xen/xenbus/xenbus_dev.c > > Also please try using a search engine to answer these questions. This > driver is trivially found with google. > > Ian. > >> By the way, which driver use the socket file as backend ?..._______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell
2012-Aug-09 11:00 UTC
Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`
On Thu, 2012-08-09 at 11:49 +0100, 马磊 wrote:> By the way, which driver use the socket file as backend ?...You mean who uses the unix domain socket interface to xenstored? libxenstore can optionally use this if it happens to be running in the same domain as the daemon. Otherwise it will use the /proc/xen/xenbus method. Please, try (harder) to use grep, google etc to find the answers to these things, you are asking a lot of questions which you really ought to be able to answer by studying the code a bit. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, Aug 9, 2012 at 7:00 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Thu, 2012-08-09 at 11:49 +0100, 马磊 wrote: > > > By the way, which driver use the socket file as backend ?... > > You mean who uses the unix domain socket interface to xenstored? > > libxenstore can optionally use this if it happens to be running in the > same domain as the daemon. Otherwise it will use the /proc/xen/xenbus > method. > > Please, try (harder) to use grep, google etc to find the answers to > these things, you are asking a lot of questions which you really ought > to be able to answer by studying the code a bit. > > Ian. > >I got xen source code from http://www.xen.org/download/index_4.1.2.html . when using `xl restore`，xc_evtchn_alloc_unbound will raise this error: xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1 (3 = No such process): Internal error. what does this mean and what does such process refer to? Looking forward to your reply. Thanks. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell
2013-Jan-02 14:34 UTC
Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`
On Wed, 2012-12-26 at 09:53 +0000, 马磊 wrote:> > I got xen source code from > http://www.xen.org/download/index_4.1.2.html . > when using `xl restore`，xc_evtchn_alloc_unbound will raise this > error: xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1 > (3 = No such process): Internal error. > what does this mean and what does such process refer to?"No such process" is what strerror(3) returns for ESRCH. In this case it won't be a process which is not found but most likely it is the event channel. (this misuse of terminology is a symptom of reusing the POSIX errno numbers in the hypercall interface) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Wed, Jan 2, 2013 at 10:34 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Wed, 2012-12-26 at 09:53 +0000, 马磊 wrote: > > > > > I got xen source code from > > http://www.xen.org/download/index_4.1.2.html . > > when using `xl restore`，xc_evtchn_alloc_unbound will raise this > > error: xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1 > > (3 = No such process): Internal error. > > what does this mean and what does such process refer to? > > "No such process" is what strerror(3) returns for ESRCH. In this case it > won''t be a process which is not found but most likely it is the event > channel. (this misuse of terminology is a symptom of reusing the POSIX > errno numbers in the hypercall interface) > > Ian. > >Thanks for your kindness! I looked into the functions for logging, in this case, `3 = No such process` was from `errno` and the ` HYPERVISOR_event_channel_op failed: -1 ` was from hypervisor-level error(src/xen/common/event_channel.c). In my option, that''s to say, error number of -1 was caused by hypervisor; but what was the error number of 3 caused by, dom0? Do both the two error numbers refer to the description defined in errno.h or else hypervisor has its own error description? I run `xl restore` in sudo mode, it had no reason for `EPERM`. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Fri, Jan 4, 2013 at 11:55 AM, 马磊 <aware.why@gmail.com> wrote:> > > On Wed, Jan 2, 2013 at 10:34 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote: > >> On Wed, 2012-12-26 at 09:53 +0000, 马磊 wrote: >> >> > >> > I got xen source code from >> > http://www.xen.org/download/index_4.1.2.html . >> > when using `xl restore`，xc_evtchn_alloc_unbound will raise this >> > error: xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1 >> > (3 = No such process): Internal error. >> > what does this mean and what does such process refer to? >> >> "No such process" is what strerror(3) returns for ESRCH. In this case it >> won''t be a process which is not found but most likely it is the event >> channel. (this misuse of terminology is a symptom of reusing the POSIX >> errno numbers in the hypercall interface) >> >> Ian. >> >> > Thanks for your kindness! > > I looked into the functions for logging, in this case, `3 = No such > process` was from `errno` and the ` HYPERVISOR_event_channel_op failed: > -1 ` was from hypervisor-level error(src/xen/common/event_channel.c). > In my option, that''s to say, error number of -1 was caused by hypervisor; > but what was the error number of 3 caused by, dom0? > Do both the two error numbers refer to the description defined in errno.h > or else hypervisor has its own error description? > > I run `xl restore` in sudo mode, it had no reason for `EPERM`. >Besides, the error `ESRCH` is raised by src/xen/common/event_channel.c:evtchn_bind_interdomain 160-static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind) 161{ 162 struct evtchn *lchn, *rchn; 163 struct domain *ld = current->domain, *rd; 164 int lport, rport = bind->remote_port; 165 domid_t rdom = bind->remote_dom; 166 long rc; 167 168 if ( rdom == DOMID_SELF ) 169 rdom = current->domain->domain_id; 170 171 if ( (rd = rcu_lock_domain_by_id(rdom)) == NULL ) 172 return -ESRCH; but in actually, the error `xc_evtchn_alloc_unbound will raise this error: xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1 (3 = No such process): Internal error.` I mentioned above is caused by src/xen/common/event_channel.c:evtchn_alloc_unbound _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell
2013-Jan-04 09:17 UTC
Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`
On Fri, 2013-01-04 at 03:55 +0000, 马磊 wrote:> > I looked into the functions for logging, in this case, `3 = No > such process` was from `errno` and the ` HYPERVISOR_event_channel_op > failed: -1 ` was from hypervisor-level > error(src/xen/common/event_channel.c). > In my option, that's to say, error number of -1 was caused by > hypervisor; but what was the error number of 3 caused by, dom0? > Do both the two error numbers refer to the description defined in > errno.h or else hypervisor has its own error description?This is just the usual Unix idiom where system calls (and by extension the ioctl used to make hypercalls) fail by returning -1 (which has no particular meaning other than "an error occurred") and set errno to something more specific (3 in this case, indicating ESRCH). Please see the errno(3) man page. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Fri, Jan 4, 2013 at 5:17 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Fri, 2013-01-04 at 03:55 +0000, 马磊 wrote: > > > > > I looked into the functions for logging, in this case, `3 = No > > such process` was from `errno` and the ` HYPERVISOR_event_channel_op > > failed: -1 ` was from hypervisor-level > > error(src/xen/common/event_channel.c). > > In my option, that''s to say, error number of -1 was caused by > > hypervisor; but what was the error number of 3 caused by, dom0? > > Do both the two error numbers refer to the description defined in > > errno.h or else hypervisor has its own error description? > > This is just the usual Unix idiom where system calls (and by extension > the ioctl used to make hypercalls) fail by returning -1 (which has no > particular meaning other than "an error occurred") and set errno to > something more specific (3 in this case, indicating ESRCH). > > Please see the errno(3) man page. > > Ian. > > Does the xen hypervisor set the errno to something specific when xenencounter an error? Where are the hypervisor error descriptors and dom0 error descriptors defined respectively? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell
2013-Jan-04 11:48 UTC
Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`
On Fri, 2013-01-04 at 11:38 +0000, 马磊 wrote:> > > On Fri, Jan 4, 2013 at 5:17 PM, Ian Campbell <Ian.Campbell@citrix.com> > wrote: > On Fri, 2013-01-04 at 03:55 +0000, 马磊 wrote: > > > > > I looked into the functions for logging, in this case, > `3 = No > > such process` was from `errno` and the ` > HYPERVISOR_event_channel_op > > failed: -1 ` was from hypervisor-level > > error(src/xen/common/event_channel.c). > > In my option, that's to say, error number of -1 was caused > by > > hypervisor; but what was the error number of 3 caused by, > dom0? > > Do both the two error numbers refer to the description > defined in > > errno.h or else hypervisor has its own error description? > > > This is just the usual Unix idiom where system calls (and by > extension > the ioctl used to make hypercalls) fail by returning -1 (which > has no > particular meaning other than "an error occurred") and set > errno to > something more specific (3 in this case, indicating ESRCH). > > Please see the errno(3) man page. > > Ian. > > Does the xen hypervisor set the errno to something specific when xen > encounter an error?No, errno handling is a function of the libc. Please use google to lookup how system calls and errno etc work on a Linux system.> Where are the hypervisor error descriptors and dom0 error descriptors > defined respectively?Did you try grepping for them? The Xen ones are in the Xen source tree. The dom0 ones are in the Linux (or your dom0 kernel) source tree. I believe the Xen ones are a subset of the Linux ones and that the numbers are consistent. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel