Bug 884923

I think this is a device property issue. I tested it with a normally booted RHEL-6.3 guest (ie. no status=off on the qemu command line). "set_link net0 off/on" works OK functionally: the network vanishes and then returns in the guest. However the "info qtree" command in fact displays a wrong value while the link is down:

virsh # qemu-monitor-command fw-seabios63.g-rhel63.e-rhel63 --hmp --cmd info qtree
      dev: virtio-net-pci, id "net0"
        dev-prop: status = on

do_info_qtree [hw/qdev.c]
  qbus_print(main_system_bus)
    qdev_print()
      qdev_print_props() -- for device (dev / bus / parent bus props)
      qbus_print() -- recursive call for each child bus

"dev" is a DeviceState here, "status" is contained in "dev->info->props"

hw/virtio-net.h:

#define DEFINE_VIRTIO_NET_FEATURES(_state, _field) \
  [...]
  DEFINE_PROP_BIT("status", _state, _field, VIRTIO_NET_F_STATUS, true), \
  [...]

hw/virtio-pci.c:

        .qdev.name  = "virtio-net-pci",
            DEFINE_VIRTIO_NET_FEATURES(VirtIOPCIProxy, host_features),

hw/qdev.h:

#define DEFINE_PROP_BIT(_name, _state, _field, _bit, _defval) {  \
        .name      = (_name),                                    \
        .info      = &(qdev_prop_bit),                           \
        .bitnr    = (_bit),                                      \
        .offset    = offsetof(_state, _field)                    \
            + type_check(uint32_t,typeof_field(_state, _field)), \
        .defval    = (bool[]) { (_defval) },                     \
        }

So the "status" qdev property corresponds to the VIRTIO_NET_F_STATUS bit of "VirtIOPCIProxy.host_features".

This bit is not about link state -- it is unrelated to the "set_link" command. Instead, this bit describes a host feature and partakes in host-guest feature negotiation. From the virtio-0.9.5 specification:

    If the VIRTIO_NET_F_STATUS feature bit is negotiated, the link sta-
    tus can be read from the bottom bit of the "status" config field.
    Otherwise, the link should be assumed active.

That is,
- "status = on" means: the guest can inquire about the link status,
- "status = off" means: the guest can *not* inquire about the link status,
  it must assume the link is always on.

(Side point:

It looks to me like the "status = off" case is not even supported. Namely, the virtio spec also says about virtio-net's device-specific configuration fields,

    Device conguration layout

    Two configuration fields are currently defined. The mac address field
    always exists (though is only valid if VIRTIO_NET_F_MAC is set), and
    the status field only exists if VIRTIO_NET_F_STATUS is set. [...]

That means, with "status = off" the "status" field should not even be communicated to the guest. That is not the case however:

virtio_config_readb [hw/virtio.c]
  virtio_net_get_config [hw/virtio-net.c] -- via funcptr
    - copies entire "virtio_net_config" structure, including the
      hard-wired "status" field, if the guest asks for it

Side point ends.)

I'm closing this BZ as NOTABUG.

Agree with Laszlo's analysis.  Regarding the "status = off" case, I think the spec's wording is incorrect.  In general, "does not exist" means "is replaced by padding" if the configuration is big enough to include that field.  The host is free to do whatever it wants, the guest however should not trust it.