linux-kernel - Re: [Xen-devel] [PATCH 5 of 5] 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 12 Mar 2010 18:11:40 +0000
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Stefano Stabellini <Stefano.Stabellini@...citrix.com>,
	"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 5 of 5] xen pci platform device driver

On Thu, 11 Mar 2010, Jeremy Fitzhardinge wrote:
> On 03/10/2010 07:47 AM, Stefano Stabellini wrote:
> > Hi all,
> > this patch adds the xen pci platform device driver that is responsible
> > for initializing the grant table and xenbus in PV on HVM mode.
> > Few changes to xenbus and grant table are necessary to allow the delayed
> > initialization in HVM mode.
> > Finally grant table needs few additional modifications to work in HVM
> > mode.
> >
> 
> Will you add the ability to event channels via this device's interrupt
> for back-compat?
> 

I just made it work, but I am not sending another version of my patch
series with the backward compatibile callback mechanism to the list
right now because I would like to solve the issue with Sheng first: I
hope my next series is going to be based on top of his.


> > +
> > +#define XEN_IOPORT_MAGIC_VAL 0x49d2
> > +#define XEN_IOPORT_LINUX_PRODNUM 0xffff
> > +#define XEN_IOPORT_LINUX_DRVVER  ((LINUX_VERSION_CODE<<  8) + 0x0)
> >
> 
> Surely there's a better header to put this stuff?
> 

I'll move them to include/xen/platform_pci.h


> 
> Is there any way of getting these devices back?

no


> How does the unplug appear to the kernel?  Does it depend on this
> happening before the normal disk/net/etc drivers come up?

basically the devices suddenly disapper for the pci bus, so it would be
better if it happens before the disk and net drivers come up.


> Shouldn't the unplug happen as each PV device comes up, rather than
> having to pre-specify it here?
> 

this is not how current Windows PV drivers work AFAIK, but it is a good
idea. I'll try to do this in the next version.

--
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/