[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/pciif: Clarify what values go in op->err and op->result.



On Tue, Mar 31, 2015 at 05:05:23PM +0100, Ian Campbell wrote:
> On Tue, 2015-03-31 at 10:58 -0400, Konrad Rzeszutek Wilk wrote:
> > The earlier comment says that errno values go in op->err.
> > However all implementations (NetBSD, Linux) of the most
> > common operations use XEN_PCI_ERR_* instead of -EXX values.
> > 
> > The exception is the xen-pciback in Linux code when doing
> > XEN_PCI_OP_enable_msix can stash the -EXX in op->result
> > and in op->err.
> 
> i.e. both of them contain the same thing? How unhelpful!
> 
> What would be the impact of "correcting" ->result to do the right thing?
> (as documented below after this patch).

Ugh. The frontend (Linux) first checks op->err. If it is non-zero
then it returns op->err back up. If op->err is zero
but op->result is non-zero, then it returns op->result up the
stack.

The 'stack' differs depending on what XEN_PCI_OP it is.

For XEN_PCI_OP_conf_read and XEN_PCI_OP_conf_write
it expects 'err' to contain XEN_PCI_ERR* values. And it converts them.

In upstream Linux:
The XEN_PCI_OP_enable_msix it expects 'err' to contain
-EXX values.  Which means that whoever called 'pci_enable_msi_range' will
get the 'err' value.

In Linux 2.6.18, if 'err' has any value it will convert all of them
to '-EINVAL'.

For XEN_PCI_OP_enable_msi if 'err' has any value it will convert
all of them to -EINVAL.

For XEN_PCI_OP_disable_msix and XEN_PCI_OP_disable_msi it just
reports the value.

NetBSD only implements XEN_PCI_OP_conf_write and XEN_PCI_OP_conf_read.

It looks to me that the upstream Linux kernel frontend driver needs
to do what the linux-2.6.18 does (return -EINVAL if there are any errors).

> 
> > 
> > As such lets clarify what '->err' and '->result' are
> > suppose to contain.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > ---
> >  xen/include/public/io/pciif.h | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/include/public/io/pciif.h b/xen/include/public/io/pciif.h
> > index a4ba13c..535963a 100644
> > --- a/xen/include/public/io/pciif.h
> > +++ b/xen/include/public/io/pciif.h
> > @@ -71,7 +71,7 @@ struct xen_pci_op {
> >      /* IN: what action to perform: XEN_PCI_OP_* */
> >      uint32_t cmd;
> >  
> > -    /* OUT: will contain an error number (if any) from errno.h */
> > +    /* OUT: will contain an XEN_PCI_ERR_* value. */
> >      int32_t err;
> >  
> >      /* IN: which device to touch */
> > @@ -83,7 +83,9 @@ struct xen_pci_op {
> >      int32_t offset;
> >      int32_t size;
> >  
> > -    /* IN/OUT: Contains the result after a READ or the value to WRITE */
> > +    /* IN/OUT: Contains the result after a READ or the value to WRITE.
> > +     * If the err does not have XEN_PCI_ERR_success, depending on
> 
> s/the err does not have/err is not/
> 
> > +     *  XEN_PCI_OP_* might have the errno value. */
> 
> might under what circumstances? Can that be documented (perhaps as a
> default here and a small number of exceptions?)
> 
> >      uint32_t value;
> >      /* IN: Contains extra infor for this operation */
> >      uint32_t info;
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.