linux-kernel - Re: [Xen-devel] [PATCH 4 of 4] Linux pvops: xen pci platform device driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 3 Mar 2010 17:14:28 +0100
From:	Bastian Blank <waldi@...ian.org>
To:	Stefano Stabellini <stefano.stabellini@...citrix.com>
Cc:	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4] Linux pvops: xen pci platform
	device driver

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/