----- Forwarded message from Keir Fraser <keir(a)xen.org> -----
From: Keir Fraser <keir(a)xen.org>
Date: Mon, 17 Sep 2012 12:34:00 +0100
Subject: [Xen-devel] [ANNOUNCE] Xen 4.2 released!
The Xen team is pleased to announce the release of Xen 4.2.
The result of *18 months* of development, new features include:
* Paging/sharing improvements for high-density VM environments (eg. VDI)
* Enhancements to PV-HVM guest performance
* Improved memaccess (guest introspection) support
* EFI boot support, replacing the legacy BIOS boot environment
* Improved RAS support
* XL as the default toolstack; XEND officially deprecated
* Upstream QEMU support, with its up-to-date feature list
Detailed release notes, including a more extensive feature list:
To download tarballs:
Or the Mercurial source repository (tag 'RELEASE-4.2.0'):
And the announcement on the Xen blog:
Thanks to the many people who have contributed to this release!
The Xen Team
Xen-devel mailing list
----- End forwarded message -----
On 2012-09-17 21:15, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 17, 2012 at 01:42:54PM +0100, Ian Campbell wrote:
>> On Mon, 2012-09-17 at 13:32 +0100, Pasi Kärkkäinen wrote:
>>> On Mon, Sep 17, 2012 at 01:51:03PM +0200, Robin Axelsson wrote:
>>>> There is one thing I wonder though when it comes to PCI passthrough:
>>>> Can Xen reset hardware through the d3d0 in the ACPI interface and/or
>>>> through a 'bus reset' or a 'link reset'? Or can it reset hardware
>>>> that is marked for passthrough only through FLR?
>>>> For details see e.g.
>>> I added xen-devel to the CC-list.
>>> Hopefully someone there can reply this question.
>> With a pvops dom0 Xen resets devices by writing to its "reset" node in
>> sysfs so it will reset the device using whatever method the dom0 kernel
>> supports for that device.
> And if you use Xen PCI-back it has this enabled so you don't even
> need the 'reset' functionality.
>> The version of Linux I have to hand has, in __pci_dev_reset, calls to
>> the following in this order and stops after the first one which
>> * pci_dev_specific_reset (AKA per device quirks)
>> * pcie_flr
>> * pci_af_flr
>> * pci_pm_reset
>> * pci_parent_bus_reset
>> See drivers/pci/pci.c in the kernel for more info.
>> IIRC classic Xen kernels had similar code in pciback, although I don't
>> know which specific sets of actions or in which order they were tried.
>> Xen-devel mailing list
That sounds like great news, that means that FLR is not a requirement to
successfully pass through hardware without errors, as is stated in the
VTdHowTo page. So it seems that the VTdHowTo page needs to be updated
with this information.