[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] KEXEC: disconnect all PCI devices from the PCI bus on crash
On Thu, 2011-07-07 at 10:42 +0100, Jan Beulich wrote: > >>> On 07.07.11 at 11:12, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote: > > On Thu, 2011-07-07 at 10:10 +0100, Jan Beulich wrote: > >> >>> On 07.07.11 at 10:53, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > >> > On Wed, 2011-07-06 at 19:42 +0100, Konrad Rzeszutek Wilk wrote: > >> >> On Wed, Jul 06, 2011 at 01:39:12PM +0100, Andrew Cooper wrote: > >> >> > +/* Disconnect a PCI device from the PCI bus. From the PCI spec: > >> >> > + * "When a 0 is written to [the COMMAND] register, the device is > >> >> > + * logically disconnected from the PCI bus for all accesses > >> >> > except > >> >> > + * configuration accesses. All devices are required to support > >> >> > + * this base level of functionality." > >> >> > + */ > >> >> > +void disconnect_pci_device(struct pci_dev *pdev) > >> >> > +{ > >> >> > + pci_conf_write16(pdev->bus, PCI_SLOT(pdev->devfn), > >> >> > + PCI_FUNC(pdev->devfn), PCI_COMMAND, 0); > >> >> > >> >> So if you have a PCI serial card (or Intel AMT) and you are using that > >> >> for > >> >> serial output on the hypervisor line, this will turn it off. There > >> >> should > >> >> be some whitelist capability to not do it for PCI serial devices that > >> >> are > >> >> owned (used) by the hypervisor. > >> > > >> > That would be useful for debugging the kexec process itself but in the > >> > general case there won't be any further output from the hypervisor and > >> > if the kexec'd kernel wants to use the device it is going to have to set > >> > it up again anyways. > >> > >> No, not generally. Just look at Linux' early-printk code: The device > >> is assumed to be enabled (by the BIOS), as the PCI subsystem can't > >> possibly be initialized at this point already. > > > > That's arguably a debugging facility as well though. > > > >> This also means that white-listing just devices Xen uses may not be > >> enough: If Xen doesn't use a serial console (or the secondary kernel > >> wants to use some other device Xen doesn't care about - VGA or > >> other kind of console devices come to mind), it must not find it fully > >> disconnected from the bus. Consequently I would think that while > >> interrupt and DMA activity should be forced off, decoding I/O and > >> memory addresses by the devices shouldn't be. > > > > The problem is that this can't be done without device specific > > knowledge, which the hypervisor generally doesn't have and we can't get > > the device's owning domain to do anything because we are crashing. > > Why would there be any device specific knowledge needed? It's > all done through the command word, just that writing zero isn't > really appropriate. So presumably if you disable bus mastering you've effectively disabled DMA but how do you disable interrupts via the command word? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |