Next in thread → Next in month →

[PATCH] clarify net mac commands.

From
Rusty Russell <>
Date
2014-05-06T01:27:00+00:00
ID
Thread
[PATCH] clarify net mac commands.
"Michael S. Tsirkin" <> writes:
> On Mon, May 05, 2014 at 08:07:48PM +0930, Rusty Russell wrote: >> Signed-off-by: Rusty Russell <> >
> Hmm ok but legacy drivers want to use VIRTIO_NET_F_MAC so
> I think we should document it as writeable for
> transitional devices in legacy mode.
> Agree?  Oh, indeed.  We talk about writing the mac in legacy mode, but we should make it explicit.  I also noticed that we talked about legacy drivers which didn't negotiate VIRTIO_NET_F_MAC_ADDR: we meant VIRTIO_NET_F_CTRL_MAC_ADDR.  This diff on top of previous:  diff --git a/content.tex b/content.tex index 8fbdefc..6a9cc02 100644 --- a/content.tex +++ b/content.tex @@ -2983,6 +2983,9 @@ MUST format field{status} and  according to the native endian of the guest rather than  (necessarily when not using the legacy interface) little-endian.
+When using the legacy interface, field{mac} is driver-writable +which provided a way for drivers to update the MAC without +negotiating VIRTIO_NET_F_CTRL_MAC_ADDR.
subsection{Device Initialization}label{sec:Device Types / Network Device / Device Initialization}
@@ -3373,7 +3376,7 @@ MUST format field{entries} in struct virtio_net_ctrl_mac  according to the native endian of the guest rather than  (necessarily when not using the legacy interface) little-endian.
-Legacy drivers that didn't negotiate VIRTIO_NET_F_MAC_ADDR +Legacy drivers that didn't negotiate VIRTIO_NET_F_CTRL_MAC_ADDR  changed field{mac} in config space when NIC is accepting  incoming packets. These drivers always wrote the mac value from  first to last byte, therefore after detecting such drivers,
Next in thread → Next in month →