the tulip driver is used in microsofts hypver-v
as the legacy ethernet adapter for pxe booting.
to make the driver work on pc64, we need to
store the Block* pointers in a separate array
instead of stuffing them into buffer address 2
of the hardware descriptor.
also, enable the driver in the pc64 kernel.
The initial protocol handling in exportfs for
cpu and import services is a huge mess.
Saparate the code out into its own program with
its own oexportfs(4) manpage.
The OCEXEC flag used to be maintained per channel,
making it shared between all the file desciptors.
This has a unexpected side effects with regard to
channel passing drivers such as devdup (/fd),
devsrv (/srv) and devshr (/shr).
For example, opening a /srv file with OCEXEC
makes it impossible to be remounted by exportfs
as it internally does a exec() to mount and
re-export it. There is no way to reset the flag.
This change makes the OCEXEC flag per file descriptor,
so a open with the OCEXEC flag only affects the fd
group of the calling process, and not the channel
itself.
On rfork(RFFDG), the per file descriptor flags get
copied.
On dup(), the per file descriptor flags are reset.
The second modification is that /fd, /srv and /shr
should reject the ORCLOSE flag, as the files that
are returned have already been opend.
enable pci busmaster before set the fis-receive-enable
bit in the port command register.
not doing so triggers a crash in qemu like:
address_space_unmap: Assertion `mr != NULL' failed.
as qemu tries to process the dma command list as soon
as we set that flag and busmaster dma needs to be enabled
at this point.
Bhyve returns 0 in MTRRCap register, so we
can use that instead on relying on cpuid only
to see if MTRR's are supported.
That way we can get rid of the sanity check
in memory.c.
Opening a /srv file sets the close-on-exec flag on the
shared channel breaking the exportfs openmount() hack.
The devsrv tries to prevent posting a channel with the
close-on-exec or remove-on-close flags. but nothing
currently prevents this poisoning on open.
Until this gets fixed in eigther exportfs or devsrv,
i'll back out the changes that could have potential side
effects like this.
On AMD64, CR0/CR4 are 64-bit registers, with
the upper half reserved. So use uintptr type
to store the register values to get 32 bit on 386
and 64 bit on AMD64.
The -v flag now does not create a new rio window,
while -w flag does (restores the old behaviour).
This allows vmx to run under vncs and is in general
mode aligned to other emulators and programs.
