From: Bastian Blank <waldi@debian.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4 of 4] Linux pvops: xen pci platform device driver
Date: Wed, 3 Mar 2010 17:14:28 +0100 [thread overview]
Message-ID: <20100303161428.GB26656@wavehammer.waldi.eu.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1003031520320.4648@kaball-desktop>
On Wed, Mar 03, 2010 at 03:52:07PM +0000, Stefano Stabellini wrote:
> On Wed, 3 Mar 2010, Bastian Blank wrote:
> > Why is version 1 grant table the default on HVM?
> Because version 2 is known not to work on HVM, fixing this is on my TODO
> list.
Well, then the later modification to 2 in the hvm case is bogus.
> > > +/* NB. [aux-]ide-disks options do not unplug IDE CD-ROM drives. */
> > > +/* NB. aux-ide-disks is equiv to ide-disks except ignores primary master. */
> > > +static char *dev_unplug;
> > > +module_param(dev_unplug, charp, 0644);
> > > +MODULE_PARM_DESC(dev_unplug, "Emulated devices to unplug: "
> > > + "[all,][ide-disks,][aux-ide-disks,][nics]\n");
> >
> > What is this parameter about?
>
> During the initialization of the xen pci device driver, we write to a
> magic ioport that causes qemu to unplug some emulated devices, disc and
> network in particular.
> This parameter is meant to present the user a choice about what emulated
> devices to unplug.
Somehow I don't think this belongs here. It looks like a workaround, you
can always ask qemu to not bind them at the beginning and the guest
system to not provide drivers.
> > > +#define XEN_IOPORT_BASE 0x10
> >
> > Why are this constants defined in the driver themself? They only make
> > sense if there are two components making use of them.
> Yep, the other one is qemu.
Well, if it is a published interface move it into a header file.
> > > + if (request_mem_region(mmio_addr, mmio_len, DRV_NAME) == NULL) {
> > > + printk(KERN_ERR ":MEM I/O resource 0x%lx @ 0x%lx busy\n",
> > > + mmio_addr, mmio_len);
> > > + return -EBUSY;
> >
> > Why is this a sign of busy?
>
> I think we were just trying to follow the behaviour of the other drivers
> of real pci devices.
> I am not sure how this condition could happen on Xen.
I checked again. There are many different return values used, but EBUSY
seems to be the most.
Bastian
--
The heart is not a logical organ.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4
next prev parent reply other threads:[~2010-03-03 16:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 18:31 [PATCH 4 of 4] Linux pvops: xen pci platform device driver Stefano Stabellini
2010-03-03 12:17 ` [Xen-devel] " Bastian Blank
2010-03-03 15:52 ` Stefano Stabellini
2010-03-03 16:14 ` Bastian Blank [this message]
2010-03-03 18:26 ` Stefano Stabellini
2010-03-04 15:26 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100303161428.GB26656@wavehammer.waldi.eu.org \
--to=waldi@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).