When the kernel is running in a virtual machine, it cannot rely upon the
processor family to determine if the workaround for AMD Family 10h Erratum
383 should be enabled.  To enable virtual machine migration among a
heterogeneous collection of physical machines, the hypervisor may have
been configured to report an older processor family with a reduced feature
set.  Effectively, the reported processor family and its features are like
a "least common denominator" for the collection of machines.

Therefore, when the kernel is running in a virtual machine, instead of
relying upon the processor family, we now test for features that prove
that the underlying processor is not affected by the erratum.  (The
features that we test for are unlikely to ever be emulated in software
on an affected physical processor.)

PR:		186061
Tested by:	Simon Matter
Discussed with:	jhb, neel
MFC after:	2 weeks
Change fdt_setup_fdtp() from "guess then fail" to more probe-like behavior.

The old code basically said it was going to use some particular blob
without knowing whether it could successfully do so, then it would invoke
the function to do that and return its status.  If it failed, you were
done, even if other blobs might be available.  Now the code attempts to use
some particular blob and if that succeeds it says so and returns success,
otherwise it moves on to try another potential blob.

One specific problem this solves is when u-boot sets an fdtaddr variable
to point to some memory address, then doesn't actually load a blob at
that address.  Now the header check will fail, and the code will move
on to the fallback dtb compiled into the kernel (if any).
Improve logging of send errors, reporting error code and interface.
Reduce code duplication between INET and INET6.

Tested by:	Lytochkin Boris <lytboris gmail.com>