In D47855#1091215, @emaste wrote:

It's worth adding a comment in the src explaining the ordering

alternate solution committed in 525a177c165740fc697df3de5b92e58b3b41477c

I'm fine with this change as it semantically makes sense and mimics original behavior of pbuf_ctor()

In D43505#991773, @oshogbo wrote:

What about the header fields we have discussed?

In D43505#991783, @imp wrote:

Id also be tempted to always do the requests in host endian and do the happing before we submit. Likewise with the replies. Not sure how feasible that is though.

In D43425#990237, @delphij wrote:

In D43425#990231, @rew wrote:

For ZFS, the argument passed to the shell script is the
pool name to import.

Ah you are right, but the name is not guaranteed to be identical to the filename. Probably zpool import -a -d /dev/$(mdconfig $0).uzip instead? (and maybe -R $1)

incorporate feedback:

• drop vm_page_all_valid() change
• fill added leaf page with mappings

In D43218#985292, @markj wrote:

This seems fine as a stopgap. If you mail me git patches for this and the MTRR review, I'll apply them.

This looks good - thanks for the fix.

address feedback from jhb

address feedback

In D41605#980592, @markj wrote:

Why exactly do we need special handling for FREVOKE?

Do not clear knotes from the TTY until it gets dealloc'ed unless the TTY
is being revoked, in that case delete the knotes when closed is called
on the TTY.

Tested and works as expected - this will be nice to have, thanks.

In D41605#948445, @markj wrote:

How do they get removed? tty_dealloc() calls knlist_destroy(), but this presumes that knotes have already been dequeued.

In D41605#948294, @kib wrote:

What would prevent this situation for other kinds of knotes?

In D41605#948243, @kib wrote:

But then, what would guarantee liveness of the tty when its detached knote f_event method is called?

In D41605#948130, @kib wrote:

Can you show the backtrace where tty filter is called without tty lock, please?

update revision with missing chunk

In D34717#925263, @mgrooms_shrew.net wrote:

I can't tell you how disappointing it is to see comments like this after a review sits in public review for months. You could have easily voiced any of these concerns during the time leading up to the commit instead of withholding them until after it was made. What exactly is your goal hear?

In D34717#925210, @afedorov wrote:

@corvink , I think this commit is too early. Because we haven't finished supporting snapshots, but this commit already fixes the user interface for live migration, which is not finished at all.

Sorry for the late comment, but maybe this commit should be rolled back?

In D34718#925207, @afedorov wrote:

I think we should bring support for snapshots first. And enable BHYVE_SNAPSHOT by default.

looks like this is value is stated in RFC8907 section 6.1 under the authen_type header

Thanks

In D40108#913426, @gusev.vitaliy_gmail.com wrote:

At least it saves pdi.pi_cfgdata. Do you think it is waste doing and .pi_cfgdata can not be changed by guest OS or be changed between bhyve versions ?

small nits - other than that, looks good

not sure that devices should define a snapshot handler when not supported by the device.