Re: Making Lemonade (Floating-point format changes)

EricP wrote:

MitchAlsup1 wrote:

EricP wrote:
 

MitchAlsup1 wrote:

EricP wrote:
>

MitchAlsup1 wrote:

Scott Lurndal wrote:
>

I would want an option in this SR-IOV mechanism for the guest app to
tell the guest OS to tell the HV to pin the buffer before starting IO.

>
>
>
So, what happens if GuestOS thinks the user file is located on a local
SATA drive, but it is really across some network ?? This works when devices are not virtualized since the request is routed to a different
system where the file is local, accessed and data returned over the
network.
>
Does this mean the application has lost a level of indirection in order
to have become virtualized ?????

 

I don't understand your question.
My comment was about the consequences of not pinning buffer pages
before starting an I/O. If those pages were for a mapped file stored
on a network device it won't be different.

 Most of users files are on the local system and SR-IOV works fine, but one
or more of his files exist on a remote machine accessed over the internet;
and user still uses SR-IOV interface to access those files.

If by "works fine" you mean is slower and has more overhead than
just pinning the pages first as DMA I/O does now.

Yes, copy on write has this problem too when most of the address space
gets copied.

(Its more work to initiate the I/O, fail when it attempts to DMA,
interrupt cpu, run ISR which queues a DPC which queues an APC back to
the thread, which pins the pages, then restarts the I/O,
than it is to just pin the pages and start and I/O.)

How does the system provide the "file is local" illusion to a user having
SR-IOV access to a non-local file.
>
For example, user opens a file which is an ln-s (a block containing a URL to where the file is remotely stored) but user thinks file is local.

I think I see what you are getting at - how does this mechanism
transparently redirect the SR-IOV device request into a network request?

The other interpretation is that the unprivileged uses is never allowed
direct access to an SR-IOV device--those are restricted to GuestOS (or
more privileged hypervisor threads).

That link is traditionally established at file open inside the kernel file
system by cross-linking between a File Control Block (or whatever its called)
and a Network Control Block representing that file on the network.
Each file syscall request is sent to the FCB then forwarded to the NCB
and out over a network link.

As I understand it, SR-IOV is a pseudo hardware device control *register*,
whereas a disk file is a fictional logical device created by the file
system driver. I don't think one could use SR-IOV to send commands to
local file system software (maybe it could trap into the OS).

One could have *disk controller registers* attached by SR-IOV,
but a disk controller is not a file system.

So as I understand the SR-IOV mechanism, one would not be reading
local or remote files over it under any circumstance.
But my understanding is limited to what the Microsoft driver
documentation says about it.