From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: pci passthrough - VF reset at boot is dropping assigned MAC Date: Mon, 25 Apr 2011 10:41:51 -0600 Message-ID: <4DB5A44F.6040304@gmail.com> References: <4DB5A13B.4050804@gmail.com> <1303749455.3431.21.camel@x201> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: KVM mailing list To: Alex Williamson Return-path: Received: from mail-pw0-f46.google.com ([209.85.160.46]:51764 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753369Ab1DYQly (ORCPT ); Mon, 25 Apr 2011 12:41:54 -0400 Received: by pwi15 with SMTP id 15so1277231pwi.19 for ; Mon, 25 Apr 2011 09:41:53 -0700 (PDT) In-Reply-To: <1303749455.3431.21.camel@x201> Sender: kvm-owner@vger.kernel.org List-ID: 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 >> 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 >> Acked-by: Chris Wright >> Signed-off-by: Marcelo Tosatti >> >> >> 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 > >