From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Haigh Subject: Re: xsa46-4.2.patch breaks PCI passthrough? Date: Sat, 04 May 2013 08:15:24 +1000 Message-ID: <518436FC.30107@crc.id.au> References: <5180A825.4050108@crc.id.au> <51813412.9070104@crc.id.au> <51813DDC.6010608@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51813DDC.6010608@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: George Dunlap , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 05/02/2013 02:07 AM, Andrew Cooper wrote: > On 01/05/13 16:26, Steven Haigh wrote: >> On 2/05/2013 1:18 AM, George Dunlap wrote: >>> On Wed, May 1, 2013 at 6:29 AM, Steven Haigh wrote: >>>> Hi all, >>>> >>>> I've had a report lodged against my packages that the patch provided for >>>> XSA46 against Xen 4.2.1 causes PCI passthru to break. >>>> >>>> It seems that 4.2.1 *without* the XSA46 patch works perfectly. 4.2.2 does >>>> not work. >>> Have you tried this with xen-unstable tip? That would be a blocker >>> bug for the 4.3 release. >> Hi George, >> >> It hasn't been tried it against anything other than 4.2.1 & 4.2.2 as >> yet. As I'm not the end user with the problem here, I need to wait for >> feedback. >> >> I have passed the patch provided by Andrew to the bug author - when I've >> got feedback on this I'll be able to provide more information. I think >> when we've got a root cause for this then it should be simple to verify >> it on 4.3. >> > I have been investigating this issue on XenServer. > > On XenServer, PCIPassthrough to a SLES11SP1 guest is working correctly, > even with the XSA-46 patch applied. > > When passing through physical devices, my hypervisor debugging is being > triggered, but the actions of XEN_DOMCTL_irq_permission appear to be > correct, given sensible input from the Xapi toolstack. When passing > through an SRIOV virtual function, no hypervisor debugging is being > triggered. > > At a preliminary guess, I would say that XM looks to be doing something > stupid which it used to be getting away with, but is not now given the > changed in the hypervisor. > > I suspect that it will be hard to progress this issue until Gordan > applied my debugging patch and gets back with the results. > Hi Andrew, Got a reply from Gordon -> http://xen.crc.id.au/bugs/view.php?id=5 The 'xm dmesg' output shows the following: (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of mfn 4bc435: c=c000000000000002 t=7400000000000001 (XEN) **DBG perms { 16, 1 } = 0 (XEN) **DBG perms { 34, 1 } = -22 (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of mfn 4be230: c=c000000000000002 t=7400000000000001 (XEN) **DBG perms { 16, 1 } = 0 (XEN) **DBG perms { 34, 1 } = -22 The full dmesg is attached to the bug report. -- Steven Haigh