Rebuilding with CURRENT to give it a tryout - thanks for the nudge.

Thanks for the update - I'll give this a tryout.

It fixes Windows but breaks other guests.

I don't think it's that simple (already tried - see r282922 and the subsequent backout in r283168)

Thanks for making the change. I'll try and give it a test with PCI passthru.

silence == Thanksgiving vacation.

Does VNC disconnect/reconnect work ? (I'll try and test this out)

Great catch.

This is a good start.

Thanks for this work - it will be very useful.

This is fine as it stands. The potential issues with ppt devices can be addressed separately.

Didn't want to sound alarmist - just that this type of thing can upset static analyzers.

Will need to be MFC'd asap.

Looks fine. userboot doesn't have the same resource constraints as the actual loader, so it's usually fine to bump limits.

Another issue exposed by the more dynamic nature of ppt's now is that the host domain needs to be updated when a device is moved to/from the ppt state (perhaps ppt detach ?).

The conditional code is a bit invasive - would it be better just to put an "__unused" attribute on the variables in question ?

Thanks, much nicer.

All fine by me.

Thanks for doing this. I'd started on it but hadn't made a lot of progress (couldn't get a complete full build with the amd64_gcc port - blew up in the loader).

I'm fine with this.

Looks fine. This also closes PR 202321

Anish knows SVM :)

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 !