All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@novell.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH] KEXEC: disconnect all PCI devices from	 the PCI bus on crash
Date: Thu, 7 Jul 2011 11:02:45 +0100	[thread overview]
Message-ID: <4E158445.6050209@citrix.com> (raw)
In-Reply-To: <1310032414.634.208.camel@zakaz.uk.xensource.com>



On 07/07/11 10:53, Ian Campbell wrote:
> On Thu, 2011-07-07 at 10:42 +0100, Jan Beulich wrote:
>>>>> On 07.07.11 at 11:12, Ian Campbell <Ian.Campbell@eu.citrix.com> wrote:
>>> On Thu, 2011-07-07 at 10:10 +0100, Jan Beulich wrote:
>>>>>>> On 07.07.11 at 10:53, Ian Campbell <Ian.Campbell@citrix.com> 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.
>
Bit 10 of the control word is "disable assertion of INTx# pins"  (so set
bit to 1 to disable interrupts).  That should cover legacy interrupts. 
For MSI and above, disabling DMA should prevent the bus writing to the
magic local APIC addresses.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

  reply	other threads:[~2011-07-07 10:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-06 12:39 [PATCH] KEXEC: disconnect all PCI devices from the PCI bus on crash Andrew Cooper
2011-07-06 12:43 ` Jan Beulich
2011-07-06 12:46   ` Andrew Cooper
2011-07-06 18:42 ` Konrad Rzeszutek Wilk
2011-07-07  8:41   ` George Dunlap
2011-07-07  8:53   ` Ian Campbell
2011-07-07  9:10     ` Jan Beulich
2011-07-07  9:12       ` Ian Campbell
2011-07-07  9:42         ` Jan Beulich
2011-07-07  9:53           ` Ian Campbell
2011-07-07 10:02             ` Andrew Cooper [this message]
2011-07-07 10:06               ` Tim Deegan
2011-07-07 10:07               ` Ian Campbell
2011-07-07 11:25               ` Jan Beulich
2011-07-07 11:21             ` Jan Beulich
2011-07-07 11:40               ` Stefano Stabellini
2011-07-07 13:03                 ` Konrad Rzeszutek Wilk

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=4E158445.6050209@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=JBeulich@novell.com \
    --cc=konrad.wilk@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.