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
>
>
next prev parent 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