Thank you for your very detailed reply! I'm going to send a V2 which
should address all your comments.

Appreciated.  (Well, it might be worth to give other people/reviewers
some more time to process v1 and this discussion...  ;) )

Provided that there are indeed drivers (hv_storvsc and hv_netvsc)
which explicitly account for vmpacket_descriptor header, changing
max_pkt_size for individual drivers makes more sense.
However in this case I'm not sure about our reasoning of 'pkt_offset'
above. In drivers/scsi/storvsc_drv.c:

#define STORVSC_MAX_PKT_SIZE (sizeof(struct vmpacket_descriptor) +\
                              sizeof(struct vstor_packet))

Should I also change this 'sizeof(struct vmpacket_descriptor)' to
VMBUS_MAX_PKT_DESCR_SIZE? Otherwise this would not match the check in
hv_pkt_iter_first.

AFAICT, the above #define is fine, i.e., it represents an upper bound
on pkt_len as used in hv_pkt_iter_first() (this is all is required on
max_pkt_size, cf. the memcpy() in hv_pkt_iter_first()).

The same consideration, AFAICT, holds for NETVSC_MAX_PKT_SIZE.

The remarks about pkt_offset targetted the cases, such as hv_balloon,
where we can somehow upper bound

	(pkt_len - pkt_offset)

(the "packet payload"), since then an upper bound on pkt_offset would
give us an upper bound on pkt_len "for free" (associativity):

	ptk_len = (pkt_len - pkt_offset) + pkt_offset

  Andrea