[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131210183339.26294.14581.stgit@bling.home>
Date: Tue, 10 Dec 2013 11:48:27 -0700
From: Alex Williamson <alex.williamson@...hat.com>
To: bhelgaas@...gle.com, linux-pci@...r.kernel.org
Cc: ddutile@...hat.com, linux-kernel@...r.kernel.org
Subject: [PATCH 0/3] pci: virtual channel save/restore support
Turns out that even though we don't do much with virtual channel, we
still need to save/restore it around reset. The case where this comes
into play currently is a card with a switch and multiple devices, all
supporting VC (Nvidia GRID). On some platforms the system firmware
will leave all the virtual channel capabilities in their default
state, where the VC0 TC/VC map is 0xff (TC0-7 enabled over VC0).
Other systems decide to restrict the available traffic classes and
configure 0x01 (only TC0 over VC0). At handoff, everything works, but
as soon as we do a device reset, especially if done via bus reset, the
endpoint can be returned to the spec defined default rather than the
platform default. If such a device is then assigned to a guest, the
guest driver sees multiple TCs enabled, attempts to use them, and it
fails. The failure mode depends on the platform, ranging from the
driver in the guest failing to work to host panic from an unsupported
transaction.
This series attempts to implement full save/restore support for all
types of virtual channel (VC, MFVC, and VC9). The buffer sizing code
will execute for any device with these capabilities, but of couse the
actual save/restore is only done if a reset is requested for the
device, which typically means assignment to a VM. Thanks,
Alex
---
Alex Williamson (3):
pci: Generalize wait loop
pci: Add support for save/restore of extended capabilities
pci: Add Virtual Channel to save/restore support
drivers/pci/pci.c | 488 ++++++++++++++++++++++++++++++++++++++++++++++++---
include/linux/pci.h | 3
2 files changed, 459 insertions(+), 32 deletions(-)
--
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/
Powered by blists - more mailing lists