public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: KVM mailing list <kvm@vger.kernel.org>
Subject: Re: pci passthrough - VF reset at boot is dropping assigned MAC
Date: Mon, 25 Apr 2011 10:41:51 -0600	[thread overview]
Message-ID: <4DB5A44F.6040304@gmail.com> (raw)
In-Reply-To: <1303749455.3431.21.camel@x201>



On 04/25/11 10:37, Alex Williamson wrote:
> On Mon, 2011-04-25 at 10:28 -0600, David Ahern wrote:
>> Running qemu-kvm.git as of today (ffce28f, April 18, 2011) the virtual
>> function passed to the VM is losing its assigned mac address. That is,
>> prior to launching qemu-kvm, the following command is run to set the MAC
>> address:
>>
>> ip link set dev eth2 vf 0 mac 02:12:34:56:79:20
>>
>> Yet, when the VM boots the MAC address is random which is what happens
>> when the VF is reset. Looking through the commit logs between 0.13.0 --
>> the version in Fedora 14 -- and latest git I found the following:
>>
>> commit d9488459ff2ab113293586c1c36b1679bb15deee
>> Author: Alex Williamson <alex.williamson@redhat.com>
>> Date:   Thu Mar 17 15:24:31 2011 -0600
>>
>>     device-assignment: Reset device on system reset
>>
>>     On system reset, we currently try to quiesce DMA by clearing the
>>     command register.  This assumes that nothing re-enables bus master
>>     support without first de-programming the device.  Use a bigger
>>     hammer to help the guest not shoot itself by issuing a function
>>     reset via sysfs on each system reset.
>>
>>     Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>>     Acked-by: Chris Wright <chrisw@redhat.com>
>>     Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>>
>>
>> Is this the cause of the MAC address reset and is this behavior intended?
> 
> Ugh, I hope not, it's certainly not an intended side effect.  Can you
> see if the problem still happens if you revert this patch?  If it does,

I commented out the write() in the reset function and indeed the mac
address was not reset on VM boot.

> we might need more device specific reset functions to save and restore
> that extra bit of state.  I assume this is still the 82576 VF you were
> asking about before?  Thanks,

Yes. I got distracted end of last week. Response to that thread coming soon.

David


> 
> Alex
> 
> 

  reply	other threads:[~2011-04-25 16:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-25 16:28 pci passthrough - VF reset at boot is dropping assigned MAC David Ahern
2011-04-25 16:37 ` Alex Williamson
2011-04-25 16:41   ` David Ahern [this message]
2011-04-25 17:30     ` Alex Williamson
2011-04-25 17:41       ` David Ahern
2011-04-25 18:04       ` David Ahern
2011-04-25 18:36         ` Alex Williamson
2011-04-25 19:12           ` David Ahern
2011-04-25 19:18             ` Alex Williamson
2011-04-25 20:29               ` David Ahern
2011-04-25 21:17                 ` David Ahern

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=4DB5A44F.6040304@gmail.com \
    --to=dsahern@gmail.com \
    --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