public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hartmann <andihartmann@01019freenet.de>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: KVM <kvm@vger.kernel.org>
Subject: Re: vfio problem
Date: Sat, 09 Jun 2012 17:58:01 +0200	[thread overview]
Message-ID: <4FD37289.4030407@01019freenet.de> (raw)
In-Reply-To: <1339252214.26976.149.camel@ul30vt>

Alex Williamson wrote:
> On Sat, 2012-06-09 at 15:42 +0200, Andreas Hartmann wrote:
>> On Fri, 08 Jun 2012 11:35:07 -0600
>> Alex Williamson <alex.williamson@redhat.com> wrote:
>>
>>> On Fri, 2012-06-08 at 18:58 +0200, Andreas Hartmann wrote:
>>>> Hello Alex,
>>>>
>>>> You can probably say, what this message on host side means:
>>>>
>>>> kernel: [ 3902.124109] vfio_dma_do_map: RLIMIT_MEMLOCK (65536) exceeded
>>>
>>> We've hit the limit of locked pages.  Are you trying to run as root or a
>>> normal user?  If the latter, you need to play with ulimits to increase
>>> the size.
>>
>> That's what I did now. What for is this memory exactly needed? I don't
>> think for the complete VM, because the VM without the device passed
>> through works fine without it (and it comes up fine and can ssh'd). 
>> That's why I think, it's just needed for the communication between 
>> the device and the guest. But why so much then? 
>> I think I didn't got it right until now ... .
> 
> For x86 device assignment, we pin all of guest memory when doing device
> assignment.  This allows the guest to transparently use any guest
> physical address as a DMA target.  If we didn't have this memory locked,
> a page of guest memory could be swapped in the host just as the assigned
> device issued a DMA write to that page.  This would result in corrupted
> host memory.

Thanks, got it now!

>>>> The WLAN card in the VM doesn't work any more. It came up after a few
>>>> times of restarting the VM (with unbinding / rebinding - procedures).
>>>
>>> Do I recall correctly you reporting a message about the device not
>>> supporting reset for the WLAN?` 
>>
>> Yes.
>>
>>> Unfortunately devices are mostly black
>>> boxes as far as VFIO is concerned, so if the device doesn't support
>>> reset and doesn't have it's own device specific reset and doesn't simply
>>> start behaving when we restore config space, there's little for vfio to
>>> do.  We do have a bit more flexibility in performing a secondary bus
>>> reset on the bridge since we own everything below the bridge.  We
>>> probably need to consider adding a group reset ioctl to take advantage
>>> of that.
>>>
>>>> I'll see if it is reproducible. I had to reboot to get it working again.
>>>
>>> I'm definitely curious if there's anything cumulative about the locked
>>> memory problem above.  Thanks,
>>
>> Ok, I managed to get it reproducible. I'll describe step by step, how.
>>
>> - setting low memory (64k)
>> - start VM:
>>   qemu-system-x86_64: vfio_dma_map(0x7fbfcf4fd170, 0x00000000febe0000, 0x10000, 0x7fbfb57b0000) = -12 (Cannot allocate memory)
>>   Jun  9 14:11:33 host kernel: [12001.026007] vfio_dma_do_map: RLIMIT_MEMLOCK (65536) exceeded
>> - VM is up
>> - module rt2800pci in VM is loaded fine - no errors can be seen in log.
>> - but: device doesn't work (no beaconing)
> 
> I'm surprised that the driver loaded, but not surprised that it doesn't
> work since it can't do any DMA.  You were probably getting errors from
> the IOMMU in host dmesg here too, right?

No. The only errors I get on host side are the RLIMIT_MEMLOCK exceeded
errors (a lot of them).

[...]

>> I didn't manage to remove this error but with rebooting.
>> I tried w/ or w/o including the bridge to the bind procedure. I even
>> tried to get it working again by loading the module on the host. Could 
>> it be probably a issue of rt2800pci?
> 
> Quite possibly.  Since the device doesn't have a reset at the PCI level,
> it's probably getting left in a weird state, perhaps still attempting to
> do DMA from the first guest boot.  If rt2800pci isn't robust enough to
> pull the device out of this mode, there's not much to do except pull
> some kind of hard reset like rebooting the host.  We need to figure out
> how we can take advantage of this device being behind a PCI-to-PCI
> bridge and possibly issuing a secondary bus reset on that bridge which
> could get the device back to a known state.

Hm, I hoped binding pci-stub to the bridge would already do that. Maybe
it does it already, but it has no effect on this device?

Nevertheless, I'm willing to do tests if you have some code.


Thanks,
regards,
Andreas

  reply	other threads:[~2012-06-09 16:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 16:58 vfio problem Andreas Hartmann
2012-06-08 17:35 ` Alex Williamson
2012-06-09 13:42   ` Andreas Hartmann
2012-06-09 14:30     ` Alex Williamson
2012-06-09 15:58       ` Andreas Hartmann [this message]
2012-06-09 15:32     ` Andreas Hartmann
2012-06-08 17:39 ` Andreas Hartmann
2012-06-08 18:17   ` Alex Williamson
2012-06-08 19:43     ` Andreas Hartmann
2012-06-09  0:00     ` Andreas Hartmann
2012-06-09 14:09       ` Alex Williamson

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=4FD37289.4030407@01019freenet.de \
    --to=andihartmann@01019freenet.de \
    --cc=alex.williamson@redhat.com \
    --cc=kvm@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox