4096 should eventually be PAGE_SIZE but you inherited that :)

Fix up the plurality a bit in the checkin comment e.g. "If a guest tries to update the microcode register" and it's good to go :)

Support for legacy o/s's has driven much of bhyve development. I'm all for this, though I agree there should be some consolidation of code that could be shared between ATA/ATAPI and AHCI.

I'm fine with this once the ordering issue neel mentioned is fixed.

The bsd.own.mk is a result of copying the libstand Makefile when userboot was first implemented by dfr, and subsequent catchups to changes in the mk templates. I can't think of any reason why it should continue to be there.

Thanks, looks fine.

The PCI common code could probably enforce some of this (and others, such as unaligned or natural boundary crossings in accesses), but this is fine for now.

Closed by commit rS274407 (authored by @grehan).

10.0/i386 kernel bhyve guest kernel at the bhyveload prompt, before the change:

Reported at http://docs.freebsd.org/cgi/mid.cgi?CAHiafG_fD8d0kPias209SkM0faLQ=Rv3=gXtXCy2UFbsvwcrVA

Closed by commit rS273748 (authored by @grehan).

Reviewers: I'm extremely open to changing the SVM dmesg text/ordering/etc.

Short (default) output with SVM enabled:

I'd actually prefer that this remain as virtio-blk. Any decent virtualization system would prefer to use that over a h/w emulation (see Google Compute Engine, the VM configurations for Specvirt runs). Plus, having this for the disk device gets better coverage for bhyve at what I think is a negligible cost of not having the ATA-style disk name during installation.

Agreed on the merge-rx stuff. Not sure the API can handle it the way it is written, but that can be changed.

Please remove debug printfs before submitting.

There is the possibility for frame reordering even with the netisr queue. Consider the case of a fragment train preceding a non-fragmented packet in the same connection. Other than the first one, the fragments will most likely arrive on a different queue than the following non-fragmented packet. By the time the last fragment has been reassembled and requeued, it is highly probable that the following packet has already been processed (depending on queue lengths in the adapter, and what work the pcbgroups are doing).

Looks good.

My comments about PCBGROUPs and how they deal with packets not belonging to a group's PCB list are based on a proprietary implementation that may behave differently. In any event, it would seem prudent not to do direct dispatch since that would seem to have a high chance of ending up in the wrong context/group.

It would be better if these two topics were split into separate reviews.

Excellent, please commit !

Looks fine.

Looks good !