[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Dom0 linux 4.0 + devel/for-linus-4.1 branch: p2m.c:884:d0v0 gfn_to_mfn failed! gfn=ffffffff001ed type:4



Tuesday, April 14, 2015, 10:42:39 PM, you wrote:

> On Mon, Apr 13, 2015 at 05:11:44PM +0200, Sander Eikelenboom wrote:
>> 
>> Monday, April 13, 2015, 2:21:21 PM, you wrote:
>> 
>> > On 13/04/15 13:14, Sander Eikelenboom wrote:
>> >> 
>> >> Monday, April 13, 2015, 2:07:02 PM, you wrote:
>> >> 
>> >>> On 13/04/15 12:21, Sander Eikelenboom wrote:
>> >>>>
>> >>>> Monday, April 13, 2015, 11:50:51 AM, you wrote:
>> >>>>
>> >>>>> On 13/04/15 10:39, Sander Eikelenboom wrote:
>> >>>>>> Hi David,
>> >>>>>>
>> >>>>>> I seem to have spotted some trouble with a 4.0 dom0 kernel with the 
>> >>>>>> devel/for-linus-4.1 branch pulled on top.
>> >>>>>>
>> >>>>>> Does this remind you of any specific commits in the 
>> >>>>>> devel/for-linus-4.1 branch that could
>> >>>>>> likely be involved that i could try to revert ?
>> >>>>
>> >>>>> Yes.  This will probably be 4e8c0c8c4bf3a (xen/privcmd: improve
>> >>>>> performance of MMAPBATCH_V2) which makes the kernel try harder to map
>> >>>>> all GFNs instead of failing on the first one.
>> >>>>
>> >>>>> I think this is qemu incorrectly trying to map GFNs.
>> >>>>
>> >>>>> David
>> >>>>
>> >>>> Reverted that specific one, but still get those messages.
>> >> 
>> >>> You'll have to bisect it then.  Because I don't see any other relevant
>> >>> commits in devel/for-linus-4.1
>> >> 
>> >>> David
>> >> 
>> >> Ok .. hmm first candidate of the bisect also looks interessting:
>> >> [628c28eefd6f2cef03b212081b466ae43fd093a3] xen: unify foreign GFN 
>> >> map/unmap for auto-xlated physmap guests
>> 
>> > Unless your dom0 is PVH, no.
>> 
>> > David
>> 
>> Bisection came back with:
>> 
>> 22d8a8938407cb1342af763e937fdf9ee8daf24a is the first bad commit
>> commit 22d8a8938407cb1342af763e937fdf9ee8daf24a
>> Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>> Date:   Fri Apr 3 10:28:08 2015 -0400
>> 
>>     xen/pciback: Don't disable PCI_COMMAND on PCI device reset.
>> 
>>     There is no need for this at all. Worst it means that if
>>     the guest tries to write to BARs it could lead (on certain
>>     platforms) to PCI SERR errors.
>> 
>>     Please note that with af6fc858a35b90e89ea7a7ee58e66628c55c776b
>>     "xen-pciback: limit guest control of command register"
>>     a guest is still allowed to enable those control bits (safely), but
>>     is not allowed to disable them and that therefore a well behaved
>>     frontend which enables things before using them will still
>>     function correctly.
>> 
>>     This is done via an write to the configuration register 0x4 which
>>     triggers on the backend side:
>>     command_write
>>       \- pci_enable_device
>>          \- pci_enable_device_flags
>>             \- do_pci_enable_device
>>                \- pcibios_enable_device
>>                   \-pci_enable_resourcess
>>                     [which enables the PCI_COMMAND_MEMORY|PCI_COMMAND_IO]
>> 
>>     However guests (and drivers) which don't do this could cause
>>     problems, including the security issues which XSA-120 sought
>>     to address.
>> 
>>     CC: stable@xxxxxxxxxxxxxxx
>>     Reported-by: Jan Beulich <jbeulich@xxxxxxxx>
>>     Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>>     Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
>> 
>> 
>> Could it be due to the kind of "split brain" relation pciback and qemu have ?
>> (qemu+libxl not setting up things like pcifront does (with event channel and 
>> conf space access going through pciback instead of qemu doing things by 
>> itself,
>> which also leads to pciback not installing a interrupt handler in dom0 for 
>> the 
>> devices since that in pciback relies on:
>>   - proper state signaling via xenbus
>>   - setting up an event channel
>>   - doing conf space acces via pciback 
>> )
>> 
>> Is there actually a technical reason why the xen pci passthrough parts in 
>> qemu
>> don't act more like pci-front for PV does:
>> setting up things properly via xenbus, event channel etc, so it would be 
>> more similar ?

> What is your qemu-xen commit id?

> With this patch reverted, what is lspci -vvv before you assign to a guest and 
> when hvmloader started?

> Thanks!
>> 
>> Or was this more a kind of an oversight when HVM's were introduced ?

> Not sure I understand the question? The XSA126 
> (http://xenbits.xen.org/xsa/xsa126-qemuu.patch)
> has a fix for enabling the proper bits in PCI_COMMAND which xen-pciback
> had disabled (which the above Linux patch fixes).


> If you have the QEMU patch in you should see a similar issue
> (I think). Unless the xen-pciback fix causes an previously unused
> path in libxl (or qemu) to be used (as before when it read the bars
> from SysFS they were zero). Hmmm.

> Could you also attach 'xl -vvvv -d create <g.cfg>' with and 
> without the kernel patch if it is not too much trouble?

> If it is - I will do it tomorrow and see if I can see an disreprancy.

>> 
>> --
>> Sander
>> 


Hi Konrad,

xen version is at last changeset 3a28f760508fb35c430edac17a9efde5aff6d1d5 
(previous unstable master before the force push which includes 
1aeb1156fa43fe2cd2b5003995b20466cd19a622 which causes the trouble reported here:
http://lists.xen.org/archives/html/xen-devel/2015-04/msg01336.html )

qemu-xen is at last changeset 727b998448e852a5e8eb570ac3a259ef62fbdacb 
plus the revert of 7665d6ba98e20fb05c420de947c1750fd47e5c07 
(due to other problem reported here: 
http://lists.xen.org/archives/html/xen-devel/2015-04/msg01121.html )

Kernels used:
nokp: Linux v4.0 + stable/for-linus-4.1
kp: nokp + 22d8a8938407cb1342af763e937fdf9ee8daf24a applied.

The device is used for passthrough is: 0a:00.0

--
Sander

Attached are:
  kp-lspci-before:   lspci -vvv with kernel-patch (bad) before guest start
  kp-lspci-during:   lspci -vvv with kernel-patch (bad) guest started
  nokp-lspci-before: lspci -vvv without kernel-patch (good) before guest start
  nokp-lspci-during: lspci -vvv without kernel-patch (good) guest started


  kp-xl:   xl -vvvv create  with kernel-patch (bad)
  nokp-xl: xl -vvvv create  without kernel-patch (good)

  kp-dmesg:   xl dmesg output with kernel-patch (bad)
  nokp-dmesg: xl dmesg output without kernel-patch (good)

  kp-xl-dmesg:   xl dmesg output with kernel-patch (bad)
  nokp-xl-dmesg: xl dmesg output without kernel-patch (good)

Attachment: kp-dmesg
Description: Binary data

Attachment: kp-lspci-before
Description: Binary data

Attachment: kp-lspci-during
Description: Binary data

Attachment: kp-xl
Description: Binary data

Attachment: kp-xl-dmesg
Description: Binary data

Attachment: nokp-dmesg
Description: Binary data

Attachment: nokp-lspci-before
Description: Binary data

Attachment: nokp-lspci-during
Description: Binary data

Attachment: nokp-xl
Description: Binary data

Attachment: nokp-xl-dmesg
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.