This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] KEXEC: disconnect all PCI devices from the PCI b

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

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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>