I don't follow why qemu clearing "pointers" means that we realloc the virtqueues in the guest. The host virtqueue state is reinitialized as part of the reinit process. Also, what do you believe has "recently" changed in qemu's virtio_reset? The blame shows very little changes in the last several years.

In D8803#185745, @adrian wrote:

looks good! do you need this committed?

I'm not against this idea, but, yes, when I first wrote virtio_console I didn't implement this because I didn't consider it very useful.

In D1435#178550, @rwindz0_gmail.com wrote:

What's the status of this patch. It looks very promising.
In fact I was writing kvmclock support code myself until I found this one. I think it is much better than the old tsc code.

First, thanks for this work! I had meant to add VNET support shortly after I committed this, but other stuff got in the way. Just a few initial high level comments:

• I think using a counter(9) is overkill for those stats.
• I'd really prefer to not lose the functionality provided by vxlan_ftable_sysctl_dump(). It is a very handy debugging feature, albeit even in its limited state.

Closed by commit rS278183 (authored by @bryanv).

In D1431#5, @jhb wrote:

One thing I'm worried about is that it looks like you only set the vendor name if a hypervisor "driver" calls hypervisor_register(), so that means we won't announce any "unknown" hypervisor vendor? Right now we will always pull hv_vendor out of cpuid if the cpuid leaf is valid, even if it is a hypervisor that we don't currently have a driver for. I think we don't want to lose this feature.

In D1429#6, @royger wrote:

Thanks for doing this, the change looks fine, but could you wait until Friday so I can test it on Xen before committing it?

In D1240#9, @andrew wrote:

Does anyone have any problems with this change? I would like to push this soon.

In D1149#9, @alfredperlstein wrote:

In D1149#6, @bryanv wrote:

DragonflyBSD has device_getenv_int() that does something similar - device specific query with fallback to a global value. Maybe it is a good idea to add a similarly named function so it can be available to all drivers?

That would be pretty easy, code is simple:

int
device_getenv_int(device_t dev, const char *knob, int def)
{
        char env[128];

        ksnprintf(env, sizeof(env), "hw.%s.%s", device_get_nameunit(dev), knob);
        kgetenv_int(env, &def);
        return def;
}

Do we want hw.igb0.num_queues or hw.igb.0.num_queues?

I think in FreeBSD we are doing the latter (the unit number is a separate node in the mib). So for us this would be something like:

int
device_getenv_int(device_t dev, const char *knob, int def)
{
        char env[128];

        ksnprintf(env, sizeof(env), "hw.%s.%d.%s", device_get_name(dev), device_get_unit(dev), knob);
        kgetenv_int(env, &def);
        return def;
}

Or is the dfly approach correct?

In D914#9, @rpaulo wrote:

What if the packet was encapsulated? Does the flag get copied over to the inner packet? If it does, then that's a bug because the flowid needs to be recalculated.

Closed by commit rS273331 (authored by @bryanv).

r271603

In D384#4, @gnn wrote:

I also saw the update and I am fine with it.

In my view of this it seems like there are two space indents which are not consistent with style(9). Is that because this is seen in a web browser or is the indent really incorrect?

Other than the indentation issue the code looks OK to me.

In D383#3, @gnn wrote:

Have you run this code with WITNESS to make sure that holding the lock when running through the tunnel does not lead to LOR?